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Washington D.C. 20231 USA 
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Dear Commissioner of Patents and Trademarks, 

I've developed a method creating a simple kind of artificial consciousness. The economic 
relevant effect is, that this method has the capability to develop requirement-satisfying 
software subroutines automatically. 

I am a single independent inventor and claim the small entity fees described in the Title 37 
Code of Federal Regulations § 1.27c (final regulations 8. Sept. 2000). 

I also claim foreign priority (Title 35 U.S.C. § 1 19 and Title 37 C.F.R. § 1.55): It was the 
2 nd November 1999, when I announced the patent to the german Patent- and Trademark- 
Office (DPMA). A copy of the Bibliography-Certification lies nearby. A publication before 
the 2 nd November 1 999 does not exist. The patent is not published until now in Germany 
because the examination is not finished. Therefore a German patent number does not exist 
yet - only the application number specified by "Foreign Application One::" in the enclosed 
application data sheet. The following data are not part of your Data Entry Format, so I 
offer them here: 

IPC-Main-Class: G06F009/44 
IPC-Accessory-Class: G06F01 5/1 8 

German Applicator's Number: 10857796 

Overview of the enclosed Forms and Application: 

• Utility-Patent Application Form (PTO/SB/05) 

• Fee Transmittal Form (PTO/SB/17) 

• Application Data Sheet (as described in "Guide for Preparing Bibliographic Data for Electronic Capture") 

• Original Entry-Acknowledgement of the german PTO ( = DPMA) [for proving the priority date] 

• Copy of the Bibliographic Data Sheet from the german PTO (=DPMA) 

• Patent-Description id. Drawings: 51 pages, (translated myself] 

• Declaration for Patent Application (PTO/SB/103 - 3 pages) 

• German version of the application: 36 pages [+1 page correction-history] 
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In the southern german federal states the 1 st November is a holiday (I live near Heidelberg 
in Baden-Wuerttemberg and the german PTO (=DPMA) is in Munich in Bavaria) - so I have 
no chance to order, receive and send to you a by the german PTO (=DPMA) certified copy 
of the first original application before the end of the priority year (2 nd Nov.). An agent of 
your office told me that it doesn't matter and that I could send to you the DPMA-certified 
copy later. 

I'll order it from the DPMA and send it to you with the information disclosure statement. 

When I look at the published OS-patents there are many references shown. I cannot offer 
you references, because my inventory is a totally new way to use a computer; 
The system itself learns programming in machine-code - world-wide I've not found any 
similar invention in the public patent-databases. 

I don't exactly know how to pay the basic fee because I don't have an US-applicant's 
number yet and I don't know to which account I should transfer the money. If it's possible 
for you, I allow you to take the $ 354 from my account 2213818 at the "Badische 
Beamtenbank" BLZ 66090800 - if this is not possible, please write me, to which bank 
account with which reference-number I should transfer the money to. 

On your form-overview-site "http://www.uspto.gov/web/forms/index.htmr a PTO/SB/35 
"Nonpublication Request" in reference to 35 U.S.C. 1 22(b)(2)(B)(i) is announced. 
In the version from the 1 Bt Feb. 2000 of the Title 35 United States Code (Patent law) 
downloaded from the website "http://www.uspto.gov/web/offices/pac/mpep/mpep. htm" 
I cannot find a (b)(2)(B)(i) in the short § 1 22 ?!? 

If possible, it would be nice if you could wait with the examination until the examination at 
the german Patent- and Trademark-Office ( = DPMA) is finished. 

With friendly greetings 




Gerd Kramer 



Enclosures like described above 



send per UPS-Express-Envelope and transmitted per Facsimile (If Vd receive an acknow- 
ledgement before the end of the 2 nd November I d not send it additional per facsimile) 
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TITLE OF THE INVENTION: 

Method for generating a simple kind of Artificial Consciousness in a computer, which has the 
capability to plan, generate automatically and execute machine-cods for the solution of arbitrary 
programming-abandonments. (Automatic Programming) 

REFERECES: 

First announcement of this utility-patent "Verfahren zur Generierung einer einfachen Form 
kunstlichen BewuBtseins im Computer zur Befahigung selbsttatig planender Erstellung von 
Maschinencode-Programmen und deren AusfOhrung zur Losung beliebiger gestellter Programmier- 
aufgaben" was the 2 nd November 1999 in Germany at the DPMA (deutsches Patent- und 
Markenamt = german Patent- and Trademark-Office). 

SPONSORSHIP STATEMENT: 
There was no sponsor for this invention and I'm a single independent inventor. 

BACKGROUND OF THE INVENTION: 

1 . Field of the Invention: 

The present invention relates to computer programming, and more particularly to automatic code 
generation. It relates also to learn-capable programs and artificial intelligence. 

2. Present State of the Art: 

Worldwide in the Field of Software-Development many employees are missing and the 
development tasks become larger and larger. 

Until now a given conceptual formulation is conceived and programmed by Software-developers. 
For relieving the programming there are "Wizards" which offer the possibility to generate basic 
parts of source-code after making interactive inputs on dialog-windows by a fixed given generator- 
scheme. 

Moreover company-specific scripts are written, which generate simple steadily repeated parts of 
source-code with variations on the same positions by reading out data out of ASCII-files. 
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In every case the user first has to develop the generating script and then has to write the ASCII 
data for to read out, or - in the case of "Wizards" - has to make user defined inputs and after the 
generation of the framo-sourcecode has to develop the intrinsic functionality of the program. 
After it the source-code has to be compiled to become executable. But such programs are not 
adaptive. 

On the area of Al there are neuronal networks / fuzzy logic which can build expert-systems, which 
can absorb external attractions and have the capability to make adaptive decisions on these 
inputs, which means a kind of adaptive control system but they will not be able to plan and 
develop and execute machine-code an learn from its execution. 

In the decision 20 W (pat) 12/76 of the german patent court artificial consciousness was tried to 
generated in a patent application by a reflexive chain of video cameras and monitors - this 
procedure has nothing to do with that method. 

BRIEF SUMMARY OF THE INVENTION: 

It's an object of the invention to create computer based artificial consciousness. 

It is another object of the present invention to provide a method for giving a computer the 
capability to learn programming for itself. 

It's a further object of the invention to provide a system to make a computer plan and develop 
programs targeted to a pregiven programming-aim or to fulfill its basic needs. 

Therefore it first captures all processor exception- vectors (for a single process-system) or task 
exception-vectors (for a multitasking version) by own analysis-routines. 

Then the system generates numbers, puts them to a defined place in memory and then sets the 
instruction-pointer to that number for to execute it, like it would be a legal opcode. 

Before the number is executed the processor's registers are set to predefined initial conditions and 
one number is executed several times using different initial conditions. 

After every number-execution the system analyses, if an exception occurred or the number caused 
a jump or a write to memory and the concerned source- and destination -registers are determined 
and also the kind of instruction, which means its mnemonic. For every execution many theoretical 
source-registers and several possible commands are possible. Therefore one number is executed by 
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many predefined different initial conditions to determine the* concerned source-register and 
operation most exactly. By the sum of the execution analysis data the command concerned 
mnemonic and the source- and destination-registers are determined. So the system itself learns to 
program in machine-code. 

Additional the absolute basic needs, which also have mono-cellars, are modelled: 

Pain means an attack to the program { = overwrite) and hunger means loss of energy, which is 

modelled by a defined register {hunger -low values). 

The program has got two valuation-systems: one concerning the basic needs and one concerning 
the fulfillment of pregiven programming aim. 

After single numbers are executed two-number-combinations are executed and the effects of these 
combinations are determined. 

The valuation system determines if the combination is good or worse concerning the basic needs 
and the fulfillment of a pregiven programming-aim (it's possible to disable one of these two 
valuation-systems) . 

The programming-aim concerning valuation-function is dynamic, which means the value-range of 
its valuation-results is valuated by a meta-valuation-system - and if the valuation-results are not 
very meaningful, which means, they're clustered near the min/max-boundaries or near zero or 
another value, the valuation-function is changed by the valuation-system itself and a revaluation 
occurs. If then the valuations results are worse than before, the modification is quashed and 
another valuation-function modification is tried until the revaluation results in unclustered 
valuation-results. 

When larger number-combinations are tried, the valuation-system omits to combine combinations 
which caused fatal exceptions, large jumps, extensive writing to memory, registers which should 
not be used, etc. or combinations which dislodge from the programming-aim. So not every 
additional number or combination in the total combination causes an exponential rise of needed 
calculation-time and disc-space. 

The larger the combination becomes the more restrictive is the programming-aim specific valuation- 
system concerning additional numbers = opcodes or combinations. Then additional combinations 
must appropriate the programming-aim. 

So the system learns to plan developing the desired routine. 

The solution-routines are retested by nearly all possible input-values and if it works fine it's 
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valuated by needed clock cycles and memory space and the most effective solution-routine then is 
disassembled and can be taken by developers to implement it into their projects as a subroutine. 

BRIEF DESCRIPTION OF THE DRAWINGS: 

Fig.1 shows the ER-diagram of the database-tables which contain the data of the AC-program. The 
in the middle shown CLT(i)-tables are created dynamically. The database is described in section 
1.3.2. 

Fig.2-18 show the names, datatypes, value-range and meanings of the table's columns - some 
with additional examples, how they're filled. These tables are described in sections 1.3.2.1 to 
1.3.2.16. 

Fig. 19-21 show the value-assignments of the OxT and CxT-tables. Here the effects of the 
executions are analyzed, and the mnemonic and source + destination-registers are determined. 

Fig. 22 shows the value-assignments of the energyspecific tables ELT and EBT, which provide the 
analysis results of the actions concerning the modelled hunger. 

Fig. 23-24 show the flow-chart of the AC-program. 

DETAILED DESCRIPION OF THE INVENTION: 
Contents: 

1. SPECIFICATION 

1 . 1 Object of the invention 

1 .2 Derivation of technical feasibility and Definition of artificial Consciousness ... 

1.2.1 Philosophical basic liberations 

1.2.2 Basic Approach for the Generation of Artificial Consciousness 

1 .3. Technical Doctrine how to generate Artificial Consciousness 

1 .3.6 Definition of the appropriated abbreviations 

1 .3.1 Procedure for generating artificial consciousness by comprehensible words 

1 .3.2 Creating the Database of the AC-Knowledge 

1 .3.2. 1 The Register-ldentifikation-Table [RIT - Fig.2] 

1 .3.2.2 The Operation-Identification-Table [OIT - Fig.4] 

1.3.2.3 The Initial-Condition-Table [ICT - Fig.3] 
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1 . SPECIFICATION 
1 .1 Object of the invention: 

The objects of the invention are: 

a) to provide automatized software-development, 

bl to create computerised artificial consciousness. 

With this method a simple form of artificial consciousness is generated using a computer, which 
acts aimless and arbitrarily in the beginning, but has the capability to learn from the effects of all 
its "behaviour", for to, when it knows the effects of every single behaviour or behaviour pattern 
< = combination), has the capability to join together its single actions targeting to a given aim or 
fulfilment of basic needs. 

1.2 Derivation of technical feasibility and Definition of artificial Consciousness: 

1.2. 1 Philosophical bash liberations: 

<... are normally no ingredient of a patent specification, but indispensable for the explanation 
of the technical feasibility) 

If the prerequisite of consciousness of man would be a kind of soul which would be adventitious 
between cygot and birth, it world be possible to locate it by cogitation experiment: 
If you would cognitive cut the head and provide the carotids with oxygen and nutrient containing 
blood, the consciousness would surely be located in the head. 

If you would isolate the brain expect of the factitious supply, no conventionally information flow 
between the individual and the environment would be possible, but the "I am "-consciousness 
would surely be present. 

Over it it's theoretical now possible to cut the cerebral lappets for seeing, listening, smelling, 
tasting, feeling, equilibration, speech and the cerebellum and nothing more would be lost. 
If the front cerebral lappets would further be cut, you'd loose the possibility to compute with 
present knowledge and on the cut of several upper cerebral lappets you'd loose reminiscence, but 
the deepest basic "I am" would be remaining. 

=> If a kind of soul would exist, it would be located on the upper End of the phylum brain ##. 

Under consideration of the fluent evolution the primates would have a "soul" too; and other 
mammals too; and all other animals too; and the single-cellars too; and plants too; and 
consequently every cell of a multicellular life form too. 

=s A border of a "soul-adventitious" or an "I am'-consciousness between the life forms is 
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missing. 

=> Every cell of our body ought have its own soul (the evolutionary specialisation to neural-cells 

is, equivalent to the prenatal cell-fissions, fluent). 
=> A soul does not exist (it's not necessary to build consciousness). 
=> Consciousness originates during the evolution compulsively automatically. 
=> Inside the "dead" molecule of the DNA is the construction plan for generating consciousness. 
=> Consciousness originates by valuation of the own actions and its effects, with the reflection 

of the valuation-results on the adapting dynamic valuation-method. 
=> If no soul is necessary for generating consciousness, but only the complex "program" of DNA, 

then consciousness is also generatable by a complex reflexive computer-program. 

1.2.2 Basic Approach for the Generation of Artificial Consciousness: 

The doing of all, including the plainest individuals conduces the fruition of its basic needs. 
These basic needs are: 

a) no achiness : = no attack against the own system and 

b) no hunger : = no imminent loss of energy 

A complex program, in which these basic needs are modelled, and which can act freely and has 
the possibility to learn reflexively what its actions effectuate (like a child) and can reflect if its 
actions improves its situation in reference to its basic needs, builds up a valuation-system, an then 
plans with the actions from its learned knowledge and reflects again and so attains consciousness. 
When it later scans its own machine-code and then tests every of its opcodes and after it all 
opcode-combinations it discerns the effect of its opcode-combinations and their context and so 
attains self-consciousness and now has the possibility of self-reproduction and the aware 
improvement of its machine-code while reproduction and so starts its evolution (its so effective 
like man could improve its DNA while mitoses/meiosis implementing its experience of life). 



1.3. Technical Doctrine how to generate Artificial Consciousness: 
1.3.0 Definition of the appropriated abbreviations: 

The programming works on every computer with any processor and on any operating-system. In 
the following p-indexed abbreviations correlate with Motorola processors, n means Intel 
processors, and ^-indexed denote PowerPC-RISC-Processors. 
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eq. = equivalent 

ASRy, = Adress Space Register 

BATV = BAT-Registers 

BC = BitCode: every Bit correlates with a Flag and combinations are allowed. 

CCfy = Conditton-Code-Register ( = Flags: Extension, Negative-, Zero-, Overflow-, Carry-) 

CISC = Complex-lnstructionSet Computer (p.e. lA^ and MCy) 

CPU = Central processing unit = Prozessor 

CfV = Condition-Register (CR 0..7) 

CrV = Control-Register 

CTRy, = Count-Register 

DABR^ = Data Adress Breakpoint Register 

DAR^ = Data Adress Register 

DB = DataBase 

DEC^ = Decrement-Register 

DR* = Debug-Register 

DSISFV = DSI Status-Register shows the reason for DSI- and Alignment-Exceptions. 

EA = Effective Adress (memory access without using a register) 

EAR^ = External Access Register 

Rse&r = Segment Register: CS; SS; DS, ES, FS, GS 

EFIags* = 32-Bit-Register with the System-Flags: IDent-, VirtuatlnterruptPending-, VirtuaHnterruptFlag- 
AlignrnentCheck-, VirtualB086Mode-, ResumeFlag-, NestedTask, InputOutputPrivilegeLevel, 
OverflowFlag, DirectionRag, InterruptEnableFlag, T/apFlag, SignFlag, ZeroFlag, Auxiliary/AUgn- 
CarryFlag, ParityFlag, CarryFlag. 

EIP^ = Extended Instruction Pointer PC^) 

ER = Entity Relationship (database-model) 

ESP* = Extended StackPointer <^USP„) 

Exc. = Exception^ #DevideError, #DeBug, NMI IRQ, #BreakPoint, #Overflow, #BoundRange 
exceeded, #UD (Invalid Opcode), #NM (device not available), #DoubleFault, invalid 
#TaskSwitch, Segment #NotPresent, #SS (StackFault), #GeneralProtection, 
#PageFault, #MF (FloatingPoint-Error), #AlignmentCheck, #MachineCheck. 
Exception^ Reset, BusError, AdressError, invalidOpCode, Div/O, CHK, TrapV, 

PriviiegeViolation, Trace, Interrupts, Traps. 
Exception^ System-Reset. Machine-Check r DSI, ISI, Ext.lnterrupt, Alignment, Program, 
Floating-Point unavailable, Decrementer, System Call, Trace, Floating-Point Assist. 

FFT = fast Fourier-Transformation 

FK = Foreign Key of a ER-Database-table 

FPR^ = Floating-Point Register 0..31 

FPSCR^= Floating-Point Status and Control Register 

GB = GigaBytes = 2 30 Bytes 



- 10 - 

GPR = General Purpose Registers: on Pentium*; EAX, EBX. ECX, EDX; ESI, EDI, EBP; ESP; EIP 

on PowerPC^ GPR 0..31 ; and on Motorola the Data- and Adress-Registers. 

IA = Intel-Architecture 

IRQ = Interrupt-Request 

AC = Artificial Consciousness 

kB = kiloBytes = 2 10 Bytes 

td = Logarithm dualis = log 2 

LR^ = Link-Register 

MB = MegaBytes = 2 20 Bytes 

MSP^r = Model Specific Register 

MSRy, = Machine State Register 

NMI = Non-Maskable-lnterrupt (highest Interrupt) 

NOP = NoOperartion-OpCode [=opcode without effect (except increment of IP^/PC^)] 

OLB = OpCode Lower Byte = last byte in the opcode 

PC M = Program-Counter ( = Pointer to the first byte in memory where the processor starts to 

fetch and execute an opcode) 

PK = Primary Key of a ER-database-table 

PVRy, = Processor Version Register 

RISC = Reduced-lnstructionSet Computer (p.e. PowerPC^ 

RT^y = instruction: return from exception (loads SR and PC from Supervisor-Stack) 

SDR1^ = SDR 1 -Register 

SPRG^, = SPRG 0..3. 

Sfy = StatusRegister (Flags^: Trace-, Supervisor-, + Interrupt-Maske: l 2 li h> + CCR-Flags) 

SR^ = Segment Registers: CS, DS, SS, ES, FS, GS 

SRy = Segment Registers 

SRR^ = Save/Restore-Register of Machine-Status 

SSP A = Supervisor-StackPointer (A7 in Supervisor-Modus) 

TBfe- = Time Base Facility: Time-Counter 2 64 -1 

TR* = Table-Register: GDTR, IDTR, LDTR, TR 

USP^ = User-StackPointer (Ade res s register A7 in User-Mode, A7' in Supervisor-Mode) 

£ = correlates 

$ = begin of a hexadecimal number 

£ = result of bit-by-bit- AND over all following values [ = V 1 & V 2 &....& V n 1 

S = result of bit-by-bit-OR over all following values l = V<i | V 2 | .... | V n ] 

T = number (sum) of the set Bits in the following value [ = (1&V) + (2&V)/2 + (4&V)/44- ...] 

V = for all of the following ... 

V = for all other ... (except the following) 
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7. 3. 1 Procedure for generating artificial consciousness by comprehensible words: 

A computer system attains consciousness, if the active program, in which basic needs are 
modelled {see 1 .3.5), has captured all exception-vectors and proceeds as follows: 
Generate a normal number, write it somewhere in the memory, put the program-counter = in- 
struction-pointer on it and execute it like it would be an opcode (= machine-code-command) and 
analyze, what its execution caused and proceed so with all numbers-»opcodes {until a maximum 
length) with many representative initial conditions (register-values and reference-contents of 
address-registers). 

Then use the saved opcodes which seldom caused an exception while using several initial 
conditions and evaluate if its execution increased or decreased its situation in due to its basic 
needs. 

Combine the opcodes, which didn't decrease the own situation, and evaluate the effects of the 
code-combination using several initial conditions and save the result of analysis. 
Plan combinations of those opcode-combinations which would increase the well being referable to 
the basic needs or could fulfill or approximate a given programming aim. 

1.3.2 Creating the Database of the AC-Knowledge: 

For to have the learned from actions persistent, and for to have convenient access to the large 
quantity of data, a relational database system with its tables and relations shown in 3.1 is created. 
For to increase access and to save hard disk capacity, equivalent primary keys in clusters and 
additional indexes for often used non-PK-rows. The ER diagram is shown in Fig.1 . 
Processor-dependant and in dependence of the number of 32-Bit-OpCodes, the database can grow 
very large and so the access speed according to it slow. Therefore RISC-Processors are more 
applicatively for the AC-Procedure than CISC-Processors. But CISC-Processors, like in the IA, use 
not very much opcodes which are longer than 24 bit, wherefore it's possible to have with striped 
tables and additional index-hard-disks and a higher "obliviousness" on inefficient opcode- 
combinations, an acceptable performance too. 
The hard disc space problem in discussed in 1.5. 

1.3.2.1 The Register-ldentifikation-Table [RIT - Fig.2]: 

In the RIT the individual descriptors of the processor-registers and -vectors are typed first: Every 
Register gets a correlated identification-number, an assigned bit in the BitCode, a character 
describing the register-type, a consecutive number of the register-type and an optional description 
of the register. The register of the processor-flags <EFIags*/Sfy) gets the RegisterJD #0. The 
exception-vectors mostly are located in memory and are no internal processor-registers - to identify 
most of these important vectors they get a RegisterJD with negative sign, which correlates with 
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the exception-number. [If exception #0 is not RESET but a real exception, then all exception-vector 
RegisterJDs are displaced by 1: Register JD = -(ExceptionNr + 1 ).] 
Fig. 2b shows a Motorola example of the RIT. 

1.3.2.2 The Operation-fdentificetion-Tabfe [OIT - Fig.4]; 

Like in the RIT the registers, here in the OIT the most important operations get an identification 
number and a bit in a BitCode. 

The Operation JType pigeonholes the operation to an operation group, described in Fig. 4c. 

The Operation Mnemonic (needn't to be exact like using assembler) and the optional 

Operation Description describe the basic command. 

1.3.2.3 The initiai-Condition-Tabie f/CT-Fig.3}: 

Because of equal opcodes could cause different effects, in this table many representative initial 
conditions referring to all positive RegisterJDs are pregiven here. For every initial condition number 
(in the fig.3-example: -31. .+30) for all positive RegisterJDs a sample of initial conditions is 
generated, p.e. using the Function in Fig. 3b. But only for all registers, which could contain 
mathematically used numbers, like data-registers, address-register- references and in the 
decremented reference of it [to include the command -(adr.reg.)J, floating-point-registers and other 
special calculation-register (like p.e. MMX). 

With the content of the address-registers its surely possible to calculate too, but their values 
mostly refer to values in memory, where the predefined reference-values of the are located. 
Therefore the initial conditions of the ad dress-register- values should only gyrate circadian through 
the references. 

The Status^/EFIagvReQ'ster higher bytes are always filled with the same initial conditions from 
SkC.actuaf_Processor_Mode. The ConditionCodes in the lowest byte of StatusyEFIag% have got 
variable initial conditions. With the Control-, Debug- and Machinestate-Registers and the other 
special registers is dealt carefully too - the always get the same default-values. 

1.3.2.4 The OpCode- Register-Table [ORT - Fig.5]: 

For every form initial values by opcode-execution changed (destination-) register, in a loop over all 
possible source-registers it's ascertained which possible operation-types of the OIT could caused 
the value in the changed (destination-) register. 

For every appropriate source-destination-register-combination a table-entry is generated (unitary 
operators get the Register JD^source^-l) and for every matching operation-type between possible 
source and destination the OIT-belonging Operations _BitCode-b\x is set [p.e. 
2 + 2 = 2*2 = 2*2 = 2«1 =2|4 = ...=4 for one or two source registers 2 (the other could be a 
constant) and one destination-register 4]. 

The ORT-columns are described in fig.5 and fig. 19 contains the value-assignment-algorithms. 
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1.3.2.5 The OpCode-Learn-Table [PL T - Fig. 6]: 

The OLT is a subsumption of the effects of the actual opcode on the various used initial 
conditions. In the first 6 columns informations of fatal effects of opcode-execution are collected. 
Then there's the difference between the instruction-pointer = program-counter -value after and 
before opcode-execution and after it the condition-codes which could have caused a jump 
[redundant to \CT.Register_Value{Register_ID=0)]. 

Then in Register changed BitCode and Register _source_BitCode the Bits of all possible destination- 
and source-registers follow out of the belonging ORT-entries and after it in max Operation BitCode 
and minJDperaiion_BitCode the bitwise ORed and ANDed BitCodes of the ORT. Operations _BitCode 
-Entries. 

The duration and time of opcode-execution are stored, and in aimvaluation analog 
VFT .Valuation _Function( ADT, aim_ Value tion_FunctionlD ) it's appraised, how valuable the opcode- 
execution is in reference to reaching the programming-aim {value-assignment is shown in fig. 20). 

1.3.2.6 The OpCode-BaseTab/e fOBT - Fig. 7): 

The opcode-base-table shows the ascertained total effect of one opcode in reference to all initial 
conditions. Fig. 21 explains, how the evaluation (column-filling) happens, for so getting a "warrant 
of apprehension" of the opcode. 

The OBT contains the resume of all executions of the opcodes, which later is necessary for the 
aim-directed planning of code combinations. 

1.3.2.7 The Combinations- Register Tables lCRT(i) - Fig. 8]: 

The Combinations-RegisterTables are created dynamically, built analog the ORT, with the 
difference, that effects of opcode-combinations are analysed here. So the CBT(2) has got one 
more opcode in the primary key than the OBT = CBT(1), and CBT(3) has got three opcodes, etc. 

1.3.2.8 The Combinations- Learn Tables fCLTfi) - Fig. 91: 

Here the same is valid, like in the CRT(i). Analogous the OLT, one CLT(i)-row contains the effects 
of one opcode-combination in reference of the used initial conditions. 

Here first the column CLT(i). gradient aim valuation gains importance. While it was identical to 
aimyaluation in CLT(1) = 0LT, in CLT(i>2) it contains: CLT(i).aim_yaluation - CLT(i-1).aim_va!u- 
ation (see third line of fig. 20). 

1.3.2.9 The Combinations-Base- Tables ICBTii) - Fig. 10]: 

Analogous the CBT(i) show the resume of the effects of all initial conditions in reference to one 
opcode-combination. The value-assignments are shown in fig. 21. CBT(n) (where n is the largest i) 
is the combination-plan-table - it's the place where the aim-solution-program originates. 
If AD T. aim _ful1filled_Flag Function fCPT-PK) = 1 (TRUE), the solution -prog ram of the given aim is 
found and it'll be enrolled into the AST. 
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1.3.2.10 The Aim Solution Table [AST - Fig. 1 1}: 

For every given programming abandonment the found solution-programs, their lengths, execution- 
times and used registers and operations {->bitcodesl are enrolled here. 

1.3.2.11 The Aim Description Table [APT - Fig. 12]: 

The ADT assigns to every programming aim an identification-number, a short description, one 
bitcode-combination of the source- and one of the destination-registers which should be used (if 
possible) and one bitcode-combination of forbidden source- and one of forbidden destination- 
registers; further a string of former solution-programs which could be implemented, and a aim- 
solution-flagfunction which returns TRUE if the opcode-combination (program) solves the problem 
for the desired source- and destination-registers and finally an identifier which references to the 
valuationjfunction in the VFT. that appraises the closeness to the complying program ming-aim, 
which is among others dependant of this aim-solution-flagf unction. 

1.3.2.12 The Function- fdentih'cation- Table [FIT - Fig. 13, 14]: 

In the FIT basic subfunctions are provided, which can be used for composing the energy valuation- 
function. 

It s introduced in two variations: 

a. ) for generating a dynamical valuation function in SQL, 

b. ) for generating a dynamical valuation function in machine-code. 

The alterable building of a valuation function is easier to accomplish in SQL, but the execution-time 
in machine-code is much faster and every new composed SQL-valuation-function has to be parsed 
again. 

In the future the valuation-function should only be composed in machine-code. This has the 
additional advantage that the AC-program could use some solved solution-functions again as 
subfunctions in the FIT for later use for composing the valuation-function. 

1.3.2.13 The Valuation-Function-Table [VFT - Fig. 15]: 

The VFT contains the dynamic valuation-system in reference to the own "well being" (energy- 
register) and to the closeness to the programming aim(s). 

The VFT. Valuation FunctioM Type='E', SAC.Energy_Valuation_Function_ID ) appraises 
energyspecific actions and the Valuation _Function{ Type = 'A', SAC.Aim_Valuation_FunctionlD ) the 
closeness to the programming aim{s). 

The V FT. Function JD Chain contains the concatenation of the FIT.FunctionJD's, that means the 
execution-chain of the subfunctions: Here causes NUM (see fig. 13b), that the following value is used as 
a number of byte-length, VALUE denotes that the following value is the column-number of the 
CPT=CLT(n), from which actual row the value is taken, EREG means the RegisterJD of the energy- 
register, S/D_REG denotes the value out of ADT.all_source/dest_Registers_BitCode and AIM_F is the 
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result of the ADT.aimJulfiiled_Flag_Function. The unitary operations operate on the last result of the 
Functionl DCha in and the binary operations on the last two results. 

On every accommodation, enhancement, or other amelioration of these valuation-functions the 
Valuation Function JD is incremented and a new entry with the modified Valuation ^Function is 
created and the efficiency of all valuation-functions are reappraised: 

VFT. Valuation Function _value = SAC. Energy/Aim jseffj/atuation_Func(... )], for to have an 
efficiency-gradient for further improvements. 

The functionality of the dynamic valuation-system is described in 1 .3.7. 

1.3.2.14 The Status of the AC-Propram [SAC - Fig. 16): 

This table has no primary key and only one row. It contains status-informations of the AC-Program 
and two self-valuation-functions, which appraise the efficiency of the energy-valuation-function 
and of the valuation-function of the programming-aim-closeness <VFT) by evaluating the range of 
their valuation-results. 

These self-valuation-functions are, in opposite to the energy- and aim-closeness valuation- 
functions, not modifiable by the AC-program itself, but can be changed by the user. 

1.3.2. 15 The Energy-Learn-Table [EL T - Fig. 17]: 

In the ELT data are stored about all energy relevant actions over the actual initial conditions, that 
means for all opcodes and code-combinations, which pertain the last data- register. 
The valuability of an energyspecific action is appraised according to ELT. Energy valuation - 
VFT. Valuation _Function( SAC. Energy Valuation _Func ID ). 

1.3.2. 16 The Energy-Base Table [EBT - Fig. 18]: 

Like in the CBT(i) for programming-aim-closeness, in the EBT the effects of energy-changing 
opcode-combinations for all initial conditions are collected. 

1.3.3 Preparing the initial State of the System 

For to reset the system later into the initial state without booting, several pointers have to be 
latched. Afterwards all exception- vectors are intercepted by own routines, because of the initial 
trying to use arbitrary numbers as machine-opcodes, although many of these trying cause fatal 
exceptions, because they're illegal opcodes (not usable) or the opcode causes an exception on one 
of the initial conditions. Abnormal system end would be the consequence, if not all exception- 
vectors would be captured. 

In the case that the AC-program should run preclusively, you'll have to 

a.) stop multitasking by disabling it by an operating-system routine or by setting the IRQ-mask of 
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the processor to NMI. 

b. )save all system-exception-vectors. 

c. )set all system-exception-vectors to own analysing and handling routines. 

or if it should later run with other programs or perhaps with further AC-programs: 
a') increase own task-priority, 
b'lsave all task-exception -vectors. 

c f ) set the task-exception-vectors of the AC-program to own analysing and handling routines. 

d. Jsave the statusregister^ (^EFIags*) and the user-stackpointer. 

e. ) save the values of the other address-registers and of the data-registers. 

f. ) save the values of the segment-, control-, debug- and special-registers. 

g. jset exception-vectors, which load additional data to the supervisor-stack (p.e. on address- 

violation-exception several processors load additional information like access-address and 
opcode onto the supervisor-stack) to a this fact considering interceptor- routine. 

h. ) set the privilege-violation-exception-vector to a special capturing routine. 

i. ) set one trap-vector to a routine, where the system should continue inside the supervisor-mode 

after this trap occurs. 

j.) execute this trap intentionally to change the CPU-mode from user-mode to supervisor-mode (the 

system now continues on the above set routine), 
k.) set the trace-exception-vector to an own trace-routine for later effect-analysis after number-as- 

opcode execution. 

I.) set the bits in the first word on the supervisor-stack so, that when the SR is loaded from SSP, 
the trace-Flag is set and the IRQ-mask is set to NMI (p.e. this is #$8700 on Motorola) because 
while the following base-opcode-learning no interrupt should be possible and after execution the 
effects should be analysed. 

See referring to this fig. 24a. 

7.3.4 Base-learning from execution of all single opcodes: 
1.3.4. 1 OpCode generation and execution: 

a. ) Generate a 32-Bit-Number as an opcode, starting on #$0000.0000, later increase by 1. [if you 

already know the CPU instruction set, you can skip the opcodes which would overwrite 
memory (p.e. memory-move-commands).] 

b. )Set data- and address-registers, and the address-register destination-values and the values one 

DWord below on predefined test-values (initial conditions) and clear the condition-codes in 
EFIags^CR^ (or use several initial conditions too). 

c. ) Write the above generated opcode into the test-location in memory. Then fill the memory 

behind with zeros up to the maximum possible opcode-length, rf zeros mean the mnemonic 
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"ORI #0, Reg.O" (or another effectless command) or fill with NOPs. 

This is necessary because on a long command the zeros are not meaningless [and then often 
less destroying (p.e. memory overwriting) than the NOP-corresponding opcode-number], and on 
a few processors a clearing of the trace-flag is possible in the while execution used user-mode 
too, which effects the execution of the following numbers as opcodes too lif now the zeros are 
not effectless, NOPs have to be used to prevent further effects {like memory- or program- 
self overwriting)]. 

After these zeros or NOPs the Trace-Bit-Cleared handler is following. 
d.lSet content of the supervisor-stack, which is loaded by return from supervisor-mode into 
important user-registers like EFIagsy Status-Register^ IP^PC,,, etc., so, that CCR will be cleared 
or set on initial conditions, IRQ mask will be set to NMI, the trace-bit will be set and the 
supervisor-bittmask] will be cleared and the DWord behind is the location of the test-opcode. 
Now execute the return from supervisor-mode by the corresponding opcode-command (p.e. 
RTE^): EFiagSn/Status-Registefy is now loaded by above described values and the test-opcode 
executes, because \PJPC^ is loaded by its address. 

• If now a fatal exception occurs (except trace, p.e. privilege violation, etc.), the kind of 
exception is briefly shown graphically if desired, and it will be continued by generating and 
executing the next opcode. 

• If an initial condition dependant exception occurs (like address error, division by zero, ...) r a 
relation between initial condition an exception is analysed [attention: on several exceptions, 
because of trace, an in many literature not documented combination of both exceptions 
(internal processor handling) can occur (p.e. using M68000 on Trap, Chk, Div/0 in 
combination with Trace).] 

• If no exception occurs (not even trace) the opcode-execution cleared the trace-bit (should 
never occur while executing single opcodes) and the handler behind the opcode is executed. 

• On Trace-Exception (normal case) a usable opcode was generated which execution-effects 
have to be analysed now. 

1.3.4.2 Analysis of opcode-repercussion and saving the analysis-result: 

a. ) After execution the EFIagVStatus-Register^ and the data- and address-registers and the 

reference-values of the address-registers an the reference- values one DWord below an the user- 
stackpointer are saved for analysis. 

b. ) Verifying the own machine-code-checksum (of AC-Prg.) and the inactive copy in RAM (both 

without test-opcode placement): If checksum changed, the AC-program injured itself while 
executing the test-opcode (overwrote own parts of program). The corresponding corrupt-flag is 
set in the table. If the active version checksum changed jump into the inactive version, then 
compare both versions byte by byte and repair the corrupt version by replacing the bytes in the 
version with the changed checksum by the bytes from the version with the correct checksum. 

c. ) Check the supervisor-bitmask of the saved user-stackpointer on the supervisor-stack: If the 
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processor was in supervisor-mode before jumping into the exception-handler, although he was 
in user-mode during test-opcode execution, a combination of the normal trace-exception with a 
low-priority-exception occurred [p.e. on Motorola Div/O-, Trap- or Chk-Exception (not 
documented in the M68000er handbook)]. That means the processor first fetched the 
exception -vector of the just occurred low-priority-exception and loaded the statusregister and 
the program-counter onto the supervisor-stack and then he jumped, while being in this 
processor intern routine, before starting the corresponding handler of the exception-vector, into 
the trace-exception-routine, which caused a further loading of the program-counter and the 
status-register (where now the supervisor-bit(mask) is sat) onto the supervisor-stack. 
By analysing the supervisor-bit(mask) on the supervisor-stack, it's now detectable, that before 
trace another low-priority-exception occurred; and by comparison of the second saved program- 
counter below on the supervisor-stack with the low-priority exception-vectors, now the primary 
exception before trace is detectable, which corresponding exception-number is stored. 

d. ) Comparison of the \P n /PC^, on the supervisor-stack with the address (placement) of the test- 

opcode-address: If the IPy/PCy decreased, stayed unchanged, or increased by a value, which is 
larger than the longest possible opcode, the test-opcode was a jump-command. 
If the IPy/PCj, increased by 5 or more bytes and less than the longest possible opcode, it was a 
long opcode or a short forward jump. If no registers changed from initial conditions it was a 
short jump. 

This analysis-result is stored too. 

e. ) Comparison of the EFIags^Status-Register^ and of all register-values and of the address-register 

destination-values and of the destination-values one max. address-length below [because of 
-(Adr.Reg.) ], with the original-values. 

In a bitmask now it s flagged which registers or its destination-values changed and it's 
analysed, which operations on which source- and destination-registers could have happened 
(heeding changes of EFIags»/SFy and the result is stored in the ORT and OLT (see figs.5,19; 
6,20) and the OBT is actualised (fig. 7, 21 ). 

f. ) If it was a jump-command, in the EFIagVSfy «t's analysed if it was an conditional jump. 

1.3.5 Realisation of the basic needs: 

1.3.5.1 Realisation of artificial pain: 

Pain is caused by system-injuring. The basic pain in the biological evolution incidences already on 
monocellars and is the injuring of the DNA in the cell nucleus. If the ONA is damaged, the 
monocellar has to take time to repair its DNA using its resources. It does it by filling missing 
aminoacids in the defect half of the double helix by adding the complement aminoacids to the 
undamaged half. 

The AC program is loaded twice into RAM. If the AC program (or another one) executes a 
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command which overwrites a part of the active or inactive AC program, which means an injuring 
of the active or inactive code (DNA), it has the ability to recognise the damage by comparing the 
checksum, and has now to take time to repair the damaged code by comparing damaged and 
undamaged code to have information about the damage-location (valuable information for test- 
opcode analysis) and then copying the code from the undamaged version into the injured version 
to heal itself. If the active code was the injured one (had the corrupt checksum), it first has to 
jump into the inactive duplicate to prevent errors on self-healing, because the healing-routine itself 
could be damaged. 

1.3.5.2 Realisation of artificial hunger: 

Hunger means imminent loss of energy. Energy is engendered in the cells by transforming 
adenosintriphosphat to adenosindiphosphat. The energy for building up adenosintriphosphat from 
adenosindiphosphat is gained by combustion of glucose. Missing energy (ATP) makes metabolism 
and with it every action, reaction on pain, or self healing on injury, impossible. 
The "energy quantity" of the AC-program is modelable by the height of a value in a data register. 
Now it would be possible to realise hunger by decreasing the electric current to the processor by 
external reading of this data register and increasing an ohm-resistance inverse proportional to the 
register value. 

A less authentical hardware-unbound solution is possible too: 

Less energy is harmful for learn- process. Frugal values in the energyspecific data-register cause 
lower functionality on learning from opcode-executions. On less values no learning from opcode- 
execution is possible. And lowest values cause loss of the saved knowledge from earlier opcode- 
executions. If the value is zero, additional pain, which means own code injury, occurs. 
On hunger the AC-program consequently has to find and execute opcodes, which increase the 
value of the energyspecific data-register. 

Decreasing energy, which means the origin of hunger, is simulated by decreasing the 
energyspecific data-register by 1 after every action (= opcode- execution) tp.e. by the AC-program 
itself]. 

1.3.6 Planning on the criterions of the valuation-system: 

If the system tested all possible opcodes and analysed the effects of the suitable commands, it 
has now the possibility to learn planning aimed to comply its basic needs or its programming-afms: 
Therefore it combines the opcodes, executes them using all initial conditions and analyses, what 
effected the code-combination on every single initial condition. 

Because mostly longer opcode-combinations are necessary to fulfill the programming-aim, it plans 
the code combination by using only codes which caused no injury (own damage) or better no RAM 
access at all and caused no fatal exceptions (divide-error or overflow-exception are allowed) and 
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used no forbidden registers or opcodes ( ADT. unused Registers _BitCode\ ADT .unused } _Operations- 
BitCode). OpCodes which use the desired destination and source-registers are preferred 
. (ADT. a fl_source/dest_Registers_BitCode). 

ADT .aimjulfittjvaluationjnode appoints, if the valuation-function is existent in SQL or directly in 
machine-code. For the beginning user the slower SQL-version is more convenient and the specialist 
would prefer to use an asserr)b\er-aim_fuffilfed_Ffag_Function (ADT) which is transformed into 
machine-code, because it's much faster on complex valuation-functions than SQL. 

1.3.7 The dynamic-reflexive valuation-system: 

1.3-7.1 Valuation of the programming-aim closeness: 

The ADT. aimfuilfiiledJIagJunctionK AimJD ), returns TRUE, if the programming-aim is obtained 
and the VFT. Valuation Functioni Type = 'A', ADT. aim Jull filled Flag Junction, VFT .Function JD- 
Chain ), supplies a signed-byte value, which means the closeness of the actual CLT(n)-opcode- 
combination on the used initial conditions to the aim-solution. The result is stored into 
CLT(n). aim valuation and builds up in comparison with the last CLT(n-1 ) .aim valuation the gradient 
C LT( n) . gradien t aim valuation. 

Because of the solution program has to work for all initial conditions, the maximum- and the 
average valuability of the opcode-combination, both as average over all initial conditions, is stored 
in CBT(n). max_aim_valuation and CBT(n). avgjaimjra/uation ; and the gradients to the 
corresponding values of the last CBT(n-1) build up CBT(n). max_grad_aim_valuation and 
C BT( n) .a vg _grad_aim valuation . 

If the boundary-value of -128 or +127 was the valuation-result, the VFT .boundary yaiue counter 
is incremented, and analog low value counter is incremented, if a valuation-result between -16 
and +15 occurred. 

Using these statistical data, and on an analysis of all CLT(i). aim valuation -values, p.e. if you count 
the number of values in a small value-range running from min-possible-result to max-possible-result 
(-127 to +128) in dependence of the width of the value-range-window, the 
S AC. Aim Self ' Valuation Func appraises after every programming-aim attainment the valuation- 
results of the VFT. Valuation Junction and with it its efficiency. 

If the most valuation-results of the VFT .Valuation Function p.e. were near the boundary-values 

(min./max.), the valuation-function was too steep and has to be flattened, which means inside the 

VFT .Function ID Chain have to be more elements with negative FIT. Function Flatten. The 

opposite is valid, if the most valuation-results caused a high VFT \low_valuej:ounter. 

So after every solution of a programming-aim a self-valuation of the valuation-function occurs and 

a further step in the self-programming of the valuation-function. New elements are added to the 

valuation-function and sometimes elements are omitted and the steepness is adapted. 

Then the valuation is done again and it's revised if the new valuation-function would have supplied 
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a better range of valuation-results. 

if the new range of valuation-results was worse than the one before (valued by 
SAC.Airn_$elf_Vatuation_Function) then the modification of the valuation-function is quashed and 
another modification is tried. If the changing of the valuation-function ameliorated the range of 
valuation-results and the self-valuation-function returns a positive value, then it's continued with 
the next programming-task - otherwise a further amelioration of the valuation-function has to be 
done until self -valuation returns a positive value. 

1.3.7.2 The dynamic energy-valuation-function: 

The dynamic energyspecific valuation-system runs as follows: 

0.) Because of the results of the energyspecific valuation-system are constricted to the range of 

signedbyte the valuation-function is embedded into a frame: 

valuation-result := MINI MAX( valuation- function, -128), +127) ) 
UThe energy-valuation-function of 0-th order is "how saturated am I after the action ?": 

valuation-function(O) := MINI MAX( Energy _after. -128), +127) ] 
2.) The valuation-function of 1st order is "how much more saturated am I after the action than 

before ?": 

valuation-function! 1) := MINI MAX{ Energy jafter - Energy _before, -128), +127 ] 
3 J Because of the energy-register is of the type unsigned integer (DWord), the boundaries of the 

valuation would too often the result. Therefore a kind of logarithm or . . . 

valuation-function(2) := MIN[ MAX[ SQRTl Energy jafter - Energy _bef ore ), -128], +127] 
4.) Now negative energy-gradients would cause wrong signs, therefore 3rd square or ... 

valuation-function(3) MIN[ MAX[ SGN( EnergyGrad ) * SQRT( EnergyGrad), -128], +127], 

where EnergyGrad = Energy after - Energy _bef ore 
Possibly the function y2'SGN{ EnergyGrad )SQRT{ SQRT( EnergyGrad ) ) would be better, because it 
reaches exactly to the boundary-values, but maybe the boundary-values are reached very seldom 
and a subtler structuring around zero would be more important. 

This depends how often the boundaries are reached and how much energy-gradients supply small 
values. Maybe the naked result-value {Energy after) has to be weighted stronger and a valuation of 
the gradient alone is not sufficient. Moreover it had to be considered how much and which further 
registers are concerned beneath the energy-register and which and how much types of operations 
were executed, etc., and finally the execution-time of the energy-valuation-function itself. 
Therefore the energyspecific valuation-system has to be rarefied and adapted (like the valuation- 
system of intelligent biological life forms). 

Using dynamic embedded [PL/1SQL the changing and reparsing of the as string stored valuation- 
function no problem. Because of the execution-speed and the possibility of implementation of 
earlier programming-aim solutions the energy-valuation-function should be used in machine-code 
prospectively. 

The task of the amelioration of the energyspecific valuation-function is done, like the programming- 
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aim specific one, after every fulfilling of a programming-aim. 
Valuation-system and valuation-results are always reflexively. 

1.3.8 Beaching Self -Consciousness, Reproduction and Evolution: 

Through the process of self-healing on pain/damage the program knows its location in memory. It 
now has the possibility to check out the effects of its own opcodes one after another, then 
consecutive opcode-combinations etc.. and when it finally knows the effect of its total length, it'll 
reach self-consciousness and then has the possibility to reproduce itself and to ameliorate itself 
awarely while reproduction using its acquired knowledge (p.e. by removing the incommodious 
decrementing of the energy-register). 

The intelligent conscious-varying reproduction is much more preeminenced than the biologic- 
genetic one, because the latter only refers to existing genes/DNA, while the AC-program can vary 
itself by changing and extending its code intentionally using its "experience of life'. 

1 A. Conceptual Formulation of the Programming-Aim and Examples of Achievement 

To the AC-program an arbitrary programming-aim is challenged by giving one or more criterions in 

ADT. aim fulfilled _Ftag ^Function, by which it can check out, if it solved the task. 

Its job is it now to develop a program, which solves the problem for all initial-conditions. 

1.4. 1 Example 1: Developing a Program to compute the average: 

A very simple but easy to comprehend job for the AC-program could be: "write a program that 
computes the average over two integer-variables*. 

The AC-program fulfills this task, if the difference between the result and the lower number is 
equal to the difference of the higher number and the result, and this is functioning for any arbitrary 
input-numbers. 

But the AC program doesn't know the instruction-set of the processor - it knows now only the 
opcodes which caused no damage and no fatal exception and it knows the opcode-effects in 
reference to the different initial-conditions. 

Through corruption-selfhealing or the energy-register it already knows easiest abandonments like 
"execute an action which causes no pain" or "execute an action which makes me saturated". 
For attaining economic programming-arms, it now needs valuation-variables, which reveals answers 
to the following questions: 
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a. ) How much nearer or farther away from the programming-aim took me the last added opcode- 

combination (that every added single opcode of it may cause opposite effects is irrelevant). 

b. ) How many processor clock-cycles needed the solution-program. 

c) How many bytes long is my program and how many opcodes are included ? 

These answering variables (CBT-table-columns) are: 

aim valuation ; cycles of execution ; OpCodeJengthor Jump. 

The input-variables in the example-task could be in the first two data-registers (EAX n . EBX n 

respectively DO^DI^ respectively GPROy, GPR1y), here RO and R1 . 

The return-value should be the third data-register (ECX X | D2^| GPR2 V ), here R2. 

If the task is solved for arbitrary input-values, the program is ready, because it s function. 

If there are more than one solution, the one is chosen which needs less clock-cycles. 

The task-specific aim-fulfilled valuation-function, which computes OLT .aim valuation is conse- 
quently in this example: 

A DT .aim ^fulfilled _Flag_Functioni average of RO and R1 ) = { (R2-R0) = (R1 -R2) } 
Here the problem could occur, that one input-value is even and the other one is odd, which means 
that this input-combination would have no solution. To implement that the aim fulfilled Flag- 
Junction should be enhanced for integer-variables: { (R2-R0) = (R1-R2) 1 1 (R2-R0)+1 =(R1-R2) }. 
The AC-program will find several solution-programs and takes the one with the least needed clock- 
cycles. 

A possible solution would be in CBT(3): MOV R0,R2 ; ADD R1 ,R2 ; SHR R2 
{... naturally in machine-code of the used processor - using a Pentium that would be the 48-bit- 
number #$89C2.01CA.D1EA, using a Motorola that would be #$2400.D282.E2C2 and using a 
PowerPC (RISC) a 96-bit-number would be the solution). 

1.4.2 Example 2: generation of a programs for computation of the cube-root: 

A further easy development-task would be "write a program that returns the cube-root of a FFP 
(fast floating point) number"; the input-variable should be RO (EAX^) and the output-variable R3 
(EBXJ. 

The AC-program fulfills this task, if the result multiplied with its square is equal to the input-value 
(and this is valid for all initial conditions): 

=> aim Julfifled [Flag J=unction( cube root ) = { (R3*R3*R3) = R0 } (4-naturally in FFP-multiplic.) 
A single command like the square-root (FSQRT) doesn't exist for the cube root. 
The solution-program could be in CBT(8) using a Pentium II as follows: 

0pH16b): MOV CL,3 ;ECX = $????:0003 [1011.0001:0000.0011] 

Op2(16b): FLD1 ;ST(0) = 1.0 [1101.1001:1110.1000] 
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Op3(16b>: FIDIV CX 

Op4<16b): FLD EAX 

Op5(16b): FYL2X 

Op6{16b): FLD1 

Op7{16b): FSCALE 

Op8(16b): FST EBX 



;ST(0) = V 3 [1101.1110: 

:ST(0) = R0 ;ST(1) = 1 / 3 [1101.1001; 

;ST(0) = V3log 2 (R0} [1101.1001 

;ST(0) = 1 .0 ;ST( 1 ) = V 3 log 2 (R0) [ 1 1 01 . 1 001 

;ST(0) = 1.0*2M'/ 3 log 2 (R0H [1 101.1001 

;EBX = 2-[V 3 log 2 (R0)l [1101.1001 



1111.0001] 



1100.0000] 



1111.0001] 



1110.1000] 



1111.1101] 



1101.1011] 



{... naturally only the second of these columns as a 1 28-bit-number with the bits set as shown in 
the last column.) 

Hexadecimal that would be: B103-D9E8.DEF1 .D9C0:D9F1 .D9E8.D9FD.D9DB. 

This would be a possible solution-number (= program) for the given task (there* re surely shorter and 

faster solutions too). 



In both examples 1 6-bit-opcodes would be sufficient, but it's obvious, that large programming- 
aims would need much hard-disk space. Therefore the AC-program has to forget unimportant or 
error-ca using o pcod e-co mbi nations. 

7.5. 1 Table sizes: 

1ST, RIT and CIT need neglectable disk-space. 

Theoretically there could be size(OBJ) = 2 32 * £ bytes! column(i) ) = 485 GB, but also on a 
RISC processor never all 32-bit-combinations are used as a valid opcode and realistic are as an 
average on RISC processors about 28 bits 30 GB and on CISC processors about 20 bits 118 
MB [on latter the most are 16 bit-opcodes, there're a few 8-Bit- and several 24- and 32-bit- 
opcodes, and the ones which are longer 32-bits are not used (we don't need memory-to-memory- 
operations for example and the functionality of one long opcode can be substituted by two or more 
shorter opcodes). 

The 62 initial conditions can cause sizeiOU) = 2l 20 - 281 * 62 * I bytes! column(i) ) = 3 GB 
(CISC) up to 832 GB (RISC) and sizeiOKT) could reach the same quantity, considering that one 
opcode mostly pertains one destination- and one source-register (unitary ones use only the 
destination-register and a few seldom opcodes use 3 or more registers). But there could be many 
effect-belonging Operation JtitCodes, which would increase the tablespace dramatically, if it 
wouldn't be compensated by the many opcodes which cause an exception, where less information 
has to be stored. 

A much larger problem is the exponential growth of the CxT(i), because every i multiplies the 
needed tablespace by factor of 2 120 - 281 . But this is exact that what should be compensated by the 
dynamic valuation-system. It decreases its knowledge-absorption tolerance referable to the 



1.5. Needed Hard-disk-Space and Oblivion 
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remaining hard-disk space: So opcode-combinations with least CBT(i). max_aim_valuation or 

.avg aim valuation are forgotten and so will not be combined with other opcodes. 

Although if the demand of hard-disk space arrears large, this is no problem in near future. Also the 

according to the combination-possibilities and table-sizes increasing calculation-times are 

compensated by larger and faster becoming hard-disks and the increasing efficiency of the 

processors. 

1.5.2 Oblivion: 

Like all intelligent life-forms, the system has to forget unimportant and less important informations, 
because 

a. ) the disk space is limited, and 

b. ) data access time becomes slow on very large data-tables. 

Therefore after every satisfactorily achievement of objectives, when a new program mi ng-aim is 
given, the ELT and all CxT(i)-tables over a remaining disk-space dependant i are deleted, and the 
opcode-combinations in the remaining CxT(i) are revalued referable to the new programming-aim 
and forgotten opcode-combinations are added, if they're valuable for the new aim and the higher 
CxT(i) are recreated dynamically. 

1.6. Becoming Conscious 

Through try and error the program learned what effectuated every action and what are the effects 
of which sequence of actions. 

Through corruption-healing {if own code was overwritten in RAM) it had to repair its code and so it 
knows its position in memory. 

If it once knows the effect of its own machine-code, it gets self-consciousness and has the ability 
to reproduce its code and to ameliorate it while reproduction. 

Through the so initialised evolution the AC becomes complexer and better and will be able to solve 
larger and larger programming-tasks in future. 

1.7. Presentment of the Economic Advantages 

Here a totally new area of using a computer is presented. While normally in a computer run by man 
generated programs, which execute user-controlled applications, the AC-program itself develops 
and executes programming-aim oriented routines, which can later embedded into a large 
application. 
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The demand for software-development is worldwide much larger than the human potential of 
developers. 

A system which learns to write programs itself has the capability to solve smaller development- 
tasks, and will in future, after several evolution-steps, have the capability to develop complex 
programs as the solution of large tasks too, if it has got enough hard-disk space. 

The programmers will not have to develop all the routines they need - they order the routine from 
the AC-program and embed it into their application. So the companies can finish and sell their 
software-products earlier. 
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What is claimed is: 

1 . A method using a computer which automatically generates and executes machine-code, 
comprising the steps of 

a) preventing the multi-tasking of the operation-system, by setting the interrupt-mask of the 
processor to NMI or using a multitasking-disable-routine of the operating-system; 

b) capturing the processors exception-vectors by own analysis-routines; 

c) generating normal numbers and writing them into memory; 

d) backing up the current values of the processors registers; 

e) positioning the instruction- pointer = program-counter to the generated number in memory and 
executing the number like it would be a processor-opcode; and 

f) analysing the effects of this opcode-like execution of the number and storing the analysis- 
results, p.e. in a database. 

2. A method according to claim 1, wherein said step of (d) "backing up the current values of the 
processors registers" comprising the steps of: 

a) not only saving them for a later comparison but setting them to predefined initial conditions; 

b) setting them not only one time but several times to many different predefined initial 
conditions which means several executions of one number in step (e) by these different 
initial conditions for to have a more efficient analysis-determinations of possible number- 
execution-effects in step (f ). 

3. A method according to claim 2, wherein said step (If) "analysing the effects of this opcode-like 
execution of the number" further comprising the step of determining the number=opcode's 
mnemonic and its related source- and destination-registers by regarding all execution-effects of 
every initial condition. 

4. A method according to claim 3, wherein said step (1c) "generating normal numbers and writing 
them into memory" comprising the steps of combinations, which means: 
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a) taking one number which analysed results are already stored and appending another number 
with stored analysis-results to analyze the execution-effects of this two-number-combination 
and store the result. 

b) combining 2-number-combinations # which effects are already analysed, with a further 
analysed number and analysing and storing the analysis-results of the effects of these 3- 
number-combinations. 

c) combining a 3-number-combination, which effects are already analysed, with a further 
number, which effects are already analysed, or combining two 2-number-combinations, 
which effects are already analysed, and analysing and storing the effects of these 4-number- 
combinations. 

d) combining larger combinations, which effects are already analysed, with numbers or 
combinations, which effects are already analysed, and analysing and storing the effects of 
these larger combinations. 

5. A method according to claim 4, further comprising the step of using only combinations for 
further use, which got a positive value from a valuation-function, which appraises the 
valuability of the combination in reference to reaching a pregiven programming-aim, not causing 
fatal exceptions, not overwriting exception-vectors or the program, avoiding to use forbidden 
registers or extensive writes to memory or large jumps, etc. 

6. A method according to claim 5, further comprising the step of valuating and changing the 
valuation-function of the dynamic valuation-system by a meta-valuation-function valuating the 
results of the valuation-function according to clustering to boundary-values, low-values, other 
fixed values, etc., and then revaluating the results of the new valuation-function. 

7. A method according to claim 4, further comprising the step of implementing calls to operation- 
system routines which are offered in a table with entrance-address and source- and destination- 
registers. 

8. A method according to claim 7, further comprising the step of using only calls and 
combinations for further use, which got a positive value from a valuation-function, which 
appraises the valuability of the call-combination in reference to reaching a pregiven 
programming-aim, not causing fatal exceptions, not overwriting exception -vectors or the 
program, avoiding to use forbidden registers or extensive writes to memory or large jumps, etc. 

9. A method according to claim 8, further comprising the step of offering the disassembly of the 
solution-programs which solved the programming-aim. 

10. A method using a computer which automatically generates and executes machine-code. 
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comprising the steps of 

a) capturing the tasks = processes exception-vectors by own analysis-routines; 

b) generating normal numbers and writing them into memory; 

c) backing up the current values of the processors registers; 

d) positioning the i nst ruction- point er = program-counter to the generated number in memory and 
executing the number like it would be a processor-opcode; and 

e) analysing the effects of this opcode-like execution of the number and storing the analysis- 
results, p.e. in a database. 

11. A method according to claim 10, further comprising the steps of modelling the following basic 
needs: 

a) "no_pain\ where pain means damage to the own program, which is an overwriting of the 
own machine-code, which is recognised by comparing the programs checksum after every 
execution of a number or number-combination, and repairing damaged parts of the own 
machine-code from a duplication, which causes a decrementation of the energy-register for 
every damaged opcode of the own program which now has to be copied for reparation; and 

b) "nohunger", where hunger means the imminent loss of energy, where energy is modelled 
by the value of a predefined register, which causes negative effects on low values like 

- the loss of the capability of appraising combinations referable to the programming aim on 
low values of the energy-register, 

- mistakes on the valuation of the combination-execution concerning the source-registers on 
very low values of the energy-register, 

- the loss of the capability of self -repairing on "pain" on extreme low values of the energy- 
register, 

- a hardware-dependant decreasing of the power supply of the RAM (p.e. by increasing a 
resistor) on two times in series extreme low values of the energy-register, 

- a hardware-dependant decreasing of the power supply of the processor (p.e. by increasing 
a resistor) on three times in series extreme low values of the energy-register, 

and this energy-register is decremented after every action, where action means the 
execution of a number. 

12. A method according to claim 10, wherein said step of (10c) "backing up the current values of 
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the processors registers" further comprising the steps of 

a) not only saving them for a later comparison but setting them to predefined initial conditions; 

b) setting them not only one time but several times to many different predefined initial 
conditions which means several executions of one number in step (10d) by these different 
initial conditions for to have a more efficient analysis-determinations of possible number- 
execution-effects in step (10e). 

13. A method according to claim 12, wherein said step OOe) "analysing the effects of this opcode- 
like execution of the number" further comprising the step of determining the number = opcode's 
mnemonic and its related source- and destination-registers by regarding all execution-effects of 
every initial condition. 

14. A method according to claim 13, further comprising the step of valuating the effects of the 
execution of the number in reference to its basic needs, which means positive values for 
numbers, which cause no pain or increase the energy-register and negative values for numbers 
which cause above defined "pain" or "hunger". 

15. A method according to claim 14, further comprising the step of combining numbers and 
executing these combinations and valuating the effects of the executions of these 
combinations. 

16. A method according to claim 15, comprising the step of running several of these said programs 
as an extra process=task. 

17 A method according to claim 15, comprising the step of using a network topology where on 
two or more of the networked computers is running one of these programs. 

18. A method according to claim 14, further comprising the step of analysing a pregiven code by 
executing larger getting sequences of it instead of executing number-combinations, for to 
evaluate the effects these code-sequences or at least of the complete program. 

19. A method according to claim 18, further comprising the step of improving the analysed code in 
the direction of a pregiven programming-aim. 

20. A method according to claim 15, further comprising the step of implementing calls to 
operation-system routines which are offered in a table with entrance-address and source- and 
destination-registers. 
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21. A method according to claim 20, further comprising the step of using only calls and 
combinations for further use, which got a positive value from a valuation-function, which 
appraises the valuability of the call-combination in reference to reaching a pregiven 
programming -aim, not causing fatal exceptions, not overwriting exception-vectors or the 
program, avoiding to use forbidden registers or extensive writes to memory or large jumps, etc. 
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ABSTRACT OF THE DISCLOSURE: 

A method for generating a simple kind of computer based artificial consciousness, which means to 
give a in a computer running invention-pursuant program the capability to act and to know the 
effects of its actions and to plan further actions consciously. This is realized by giving the 
computer the capability to program its processor by its own and to plan that serf-programming 
targeted. This works, because the computer learns to program in machine-code by its own and it 
has got a dynamical valuation system to weight if its actions are useful or not. Further basic needs 
like n no_pain" and "no_hunger n are modelled to make it act to fulfill its basic needs. It has also the 
capability to solve a pregiven by several formulas determined programming aim, which means to 
develop logical programs which then can be implemented by users into their projects. 
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3.1 Relational Database of the AC -knowledge: 
3.1.1 ER-Diagram of the AC -Database: 



OIT 



RIT 



1 : n 



4^ 

1 ^-reference to all CxT{i), 
FIT, ELT, EBT, ADT, AST 



1:n-reference to all CxT(i), 
FIT, ELT, EBT, ADT, AST 



ICT 



1:n-ref. to all CLT(i),CRT(i) 



1 : n x m 



CBT<3) 



1 : n 



1 : n x m 



CBT(4) 



1 : n 



1 : n x m 



CBT(5) 
hereact.CPT 



1 : n 



-►etc. 



CLT{3) 



1 : n x m 



CLT(4) 



1 : n x m 



CLT<5) 



1 : n x m 



OBT 

7,21 


1 : n 


OLT 

6,20 


1 : n x m 


ORT 

5,19 


• , . 

1 : n x m 




1 












CBT(2) 

10 


1 : n 


CLT(2) 

9 


1 : n x m 
« 


CRT(2) 

a 







CRT(3) 



CRT<4) 



CRT(5) 



1:n 



ref. to all CBT(i),CLT(i> 



ref. to all CLT(i) 



AST 


11 




1:n 


ADT 


12 



n : 1 



VFT 



15 



1 : n 



1:1 



1:n 





1:n 


< 




FIT 




13,14 




1:n 



1:1 



ELT 


17,22 




1:n 


EBT 


18,22 



1:n 



SAC 



F!g.1 



16 



fig. -reference T 



drawings - page 2/19 



3. 1.2 Tables of the AC-Database: 



Registerldentification-Table: [R/T: every processor-register gets a RegJD and a Reg.BitCode] 
column: datatype value-range meaning: 



RegisterJD (PK) 


signed byte 


-128. 127 


0=F1ags-reg., = data-reg., adr.reg,, adr.reg.- 
destinations, FFP-reg., control-reg., debug-reg., etc.; 
neg.reg.lD=exception-vector-nr. (no processor-reg.) 


Register BitCode 


number 


0..2 128 -1 


2*Register ID, 0 if Register ID is negative. 


Register_type 


chard) 


1 Byte 


type of register: # = flags-reg., D = data-reg., 
A=address-reg., V = adr.-reg.-destination, E = excep 
tion-vector, etc. (processor dependant). 


Register number 


byte 


0..127 


current number of the {register-type} -registers. 


Register Description 


varchar2(32 


<32 Bytes 


optional description of the register[-reference]. 





Register BitCode 


Register type 


Register number 


Register Description 




0 


E 




{for all Exception-Vectors} 


-8 


0 


E 


8 


Privilege-Violation Exception 




0 


E 




{for all Exception-Vectors} 


0 


1 


# 


0 


Status-Register EFfags*) 


1 


2 


D 


0 


Data-Register DO 




4 


D 




(for all Data-Registers D1-D6} 


8 


8 


D 


7 


Data-Register D7 


9 


16 


A 


0 


Address-Register AO 






A 




{for all Address-Registers A1-A6} 


16 


65536 


A 


7 


Address-Register A7 < = USP/) 


17 


131072 


V 


0 


Destination of Address-Register AO 






V 




{for all Adr. -Reg. -Destinations A1-A6} 


24 


16777216 


V . 


7 


Destination of Adr.-Reg. A7 [ = (USP)1 


25 


33554432 


V 


0 


Destination before Adr.Reg AO [- 
(AO)] 






V 




{for all Adr.Reg.-Dest. before A1-A6} 


32 


$1.0000.0000 


V 


7 


Destination before Adr.Reg A7 t-(USP) 


33 


$2.0000.0000 


F 


0 


Floating-Point Data-Register FPR0 










{for ail further Registers} 



Fig. 2b {R/T in a Motorola-Example) 



column: 




datatype 


value-range meaning: 


IniConNr 


(PK) 


signed byte 


-31. .+30 


number of the initial-condition combination 


Register ID 


{PK) 


signed byte 


0..127 


see RIT 


Register Value 


integer 


0..2 32 -1 


value of the register(-reference) on actual IniConNr 



Fig. 3a 



Therefore 62*#registers test-values are generated, p.e. using the following function: 



Register_Value( IniConNr, RegisterJD ) = SGN( IniConNr ) * INT( 2 A ABS(lniConNr/2)+ Vz ) 

+ prime number! 3« Register ID ) 

,where prime_number(0) = 0 and prime number(-n) = -prime_number(n) 

[no 2 equal register(-destination)-values] m 



or similar. 



Fig.3b 
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Operation-ldentification-Tabte: [PIT: every processor-operation gets an OperJD and an Oper.BitCode] 
column: datatype value-range meaning: — 



Operation ID (PK) 


signed byte 


-1..63 


bit of the Calculation BitCode - see table below. 


Operation BitCode (FK) 


number 




2 A Calculation ID - see table below. 


Operation Type 


char(5) 


5 Bytes 


5 characters-code of the operation-type, see Fig.4c 


Operation M nemonic 


chad 5) 


5 Bytes 


abbreviation of the operation - see table below. 


Operation Description 


varchar2{32 


<32 Bytes 


optional description of the operation - see table below 



Fig.4a 





Operation BitCode 


Operation Type 




Operation Description 




0 






??? 


unknown operation 


0 


1 




111? 


TST 


set flags in dependence of reg.(-ref.) 


1 


2 




1121 


NEG 


negation [amount 


2 


4 




1121 


NOT 


bitwise inversion 


3 


8 




102 


MOV I 


const.integer->register{-reference) 


4 


16 




112+ 


ADDI 


add constant integer 


5 


32 




112- 


SUBI 


subtract constant integer 


6 


64 




113* 


MULI 


multiply constant integer 


7 


128 




123/ 


DIVT 


divide by constant integer 


8 


256 




113% 


MODI 


rest of integer-division 


9 


512 




.112* 


SHI.I 


integer-times a duplication 


10 


1.024 




:I12/ 


SHRI 


integer-times a halvation 


11 


2.048 




:I12| 


ORI 


set bits set in a constant integer 


12 


4.096 




:I12& 


ANDI 


clear bits not set in a const, integer 


13 


8.192 




:I12? 


BTSTI 


check if int-th bit is set in reg.(-ref.) 


14 


16.384 




:112? 


CMP I 


reg.(-ref.)-comparison with integer 


15 


32.768 


1122 


MOV 


move src . -reg . ( ref . )->dest . reg{ ref . ) 


16 


65.536 


1122+ 


ADD 


addition of repister(-reference) 


17 


131.072 


1122- 


SUB 


subtraction of register(-reference) 


18 


262.144 


1123* 


MUL 


multiplication of register{ -reference) 


19 


524.288 


1133/ 


DIV 


division by register! -reference) 


20 


1.048.576 


1133% 


MUD 


rest ot division oy recjisieiA-reT.j 


21 


2.097.152 


1122* 


OUT 


ranietorf raf i.timoc a Hi mlir*Atlftf"l 

regioi6ri-rei./-unieo a uupiiuauun 


22 


Jk <a A Jk A f\ jk 

4.1 94.304 
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23 


8.388.608 
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OK 


_ Kite cat in r\~f rani Qtorf -raf f3rF>nr*f>\ 

sei oils sei in ot regioien-roieieii^t;/ 


24 


16.777.216 


IT22& 


AND 


Clear Dfis noi sei in reyisien-roi./ 


25 


33.554.432 


1121? 


ol b J. 


cnecK it reg.i-rei j-in ou is sei 


26 


67.108.864 _, 


1121? 


pup 


compare rey.i-roi./ 1 wun it?y.i 


27 


134.217.728 


:PO0. 


TMP 

Ovitr 


oHH interior tn PP ./FIP— J = iumo to) 


28 


268.435.456 


CP1.< 




inrYin if PMP^ 
jump II v^lvlr v. 


29 


536.870.912 


CP1!> 


JLE 


jump if CMP < 


30 


1.073.741.824 


CP1.= 


JEQ 


jump if CMP = 


31 


2.147.483.648 


CP1!< 


JGE 


jump if CMP £ 


32 


4.294.967.296 


CP1! = 


JNE 


jump if CMP * 


33 


$2.0000.0000 


CPl . > 


JGT 


jump if CMP > 


34 


$4.0000.0000 


CP1!< 


J PL 


jump if £ 0 


35 


$8.0000.0000 


CP1.< 


JMT 


jump if <0 


36 


$10.0000.0000 


CPl. A 


JCS 


jump if carry-flag is set 


37 


$20.0000.0000 


CPl! * 


JCC 


jump if carry-flag is clear 


38 


$40.0000.0000 


CPl.- 


JVS 


jump if overflow is set 


39 


$80.0000.0000 


CPU- 


JVC 


jump if overflow is clear 


40 


$100.0000.0000 


CP2.< 


DJMP 


decrement and jump if reg.(-ref.)<0 


41 


$200.0000.0000 


PS1. . 


CALL 


PCu/BPjr-MUSPw/ESPJ ; + JUMP 


42 


$400.0000.0000 


SP11. 


RET 


(USPu/ESP*)* -+PCJE\P* 


43 


$800.0000.0000 


.1. . . 


I??? 


unknown integer-operation 


44 


n ooo.oooo.oooo 


,F. . . 


F?? ? 


unknown floating-point-operation 



drawings - page 4/19 



4o 


k onon f\c\f\(\ (\C\f\C\ 


£CU3 


TTMTT 


initialise) floatina-ooint-unit 

IMILIullOO II wo Lilly pwnii ui if ^ 


4o 


a r\r\c\ AnrtA c\C\f\f\ 


C 1 14 


FTQT 
r id i 


crtnrA flrtQ't' noinKrpn — ->intPfl^r-rfiO 

3l(Jlt7 1 IUa L. f 11 1 . ~H • lCyi<l • ^ cf • 


47 


ac\c\c\ f\(\f\f\ nnnn 


it iz 


TTTT n 


InaH inton^r-ron —^'flontirm-nfiint-rpfl. 
IUcjU i m icy oi t?y • ^iiuauiiy pwim ioy« 


48 


$1 .0000*2*" 


IF22 + 


r ±J\ul) 


flnatinn rtftirtfr ±kMM A nnctant i n ton A r 
llOoliny-pQin l duu UUlloiaiil iiuoyci 


49 


$2.0000*2-" 


IF22- 


FISUB 


f l^at-i fm-* wiinf- oi i \-ttr£if*t A onct intonpf 

iiOaxiny-pOini suoiraci .^unsi. initjytsi 


50 


$4.0000 +2*** 


IF22* 


rTMrn 

r J.MUJ-* 


flnotinn rwtifvt mi iftintv/ /v^nct intPnAr 

iioauny-poiriu rnumpiy cur»i.inLoyof 


51 


$8.0000*2*" 
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FI DIV 
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52 


$10.0000*2*" 


I F2 1 ? 


FICMP 


tloat.pT.com pare wim integer— *n ago 


53 
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FLD# 


load constant to floating- pom t-reg. 


54 


$40.0000*2 32 


. F12 ! 


FABS 


Dutia rioating-poini amount 


55 


$80.0000*2 32 
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FLD 


copy floating-point-register 
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FF22 + 
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FSUB 
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$4000 0000* 2 32 
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floatina-ooint-cosine 
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$8000.0000*2 32 


.F12@ 


FATAN 


floating-point arc-tangent 


64 


$T 2 48 


FF22 + 


FEXP2 


y: =y»2 x (anykind of exp.-func.) 


65 


$2*2 48 


FF22/ 


FLOG 2 


y: =x*log?v (any fcind °^ logarithm) 


66 


$4*2^ 
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FCMP 
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Fig. 4b 

using the following operation-type character-codes: 



1st char. - source , 2nd char. = dest. . 



i 

F 
C 
P 

s 

$ 

t 



3rd char. = number of source-registers: 



unknown, ambitious letter for all possible following 
nothing 

constant number 
integer-register-lreferencel-value 
floating-point register 

condition-code register (last byte in EFIags*/SFy 
instruction-pointer / program-counter (EIP^PCJ 
stack-pointer reference-value 
comparison-operation -*flags 

a special-register like flags-, control-, debug-, ... -reg 
logical NOT for comparison in the 4th field 

if it's used as source -reg 



including destination reg. 



too 



4th char. = number of dest -registers: including flags-register but without the instruc tion-pointer 



5th char. = effect of arithmetic: 



? = unknown 
-none 

= amount | negation] bitwisejnversion 
= addition 
= subtraktion 
= multiplication 
= division 
= rest of division 

= setting of bits (mostly bitwise OR) 
= clearing of bits (mostly bitwise AND) 
= trigonometric- or exponential-function 
= greater? (CC-flags dependant action) 
= less? (CC-flags dependant action) 
-equal? (CC-flags dependant action) 
= carry? (CC-flags dependant action) 
= overflow? (CC-flags dependant action) 



t 

+ 

/ 
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I 

6 
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< 



Fig ,4c 
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OpCode-Reglster-Tabla: 10RT - by opcode id, initial-conditions concerned registers and the effect} 
column: datatype value-range meaning: 



OpCode (PK) 


integer 


0..2 32 -1 


complete instruction, truncated if > 4 bytes 


InlConNr (PK) 


signed byte 


-31.-30 


current number of the used initial conditions 


Register ID dest (PK) 


signed byte 


0..127 


one by execution concerned destination-reg. (see RIT) 


Real star ID source (PK) 


signed byte 


-1.0..127 


-1 or one possible source-register (see RIT). 


value before change 


integer 


0..2 32 -1 


register(-reference)-value before it was changed 


value after change 


integer 


0..2 32 -1 


register! -reference) -value after changing 


gradient if unsigned 


signed byte 


-128.. 127 


before/after-gradient, when defined as unsigned 


gradient if signed 


signed byte 


-128.127 


before/after-gradient, when defined as signed 


value source 


integer 


0..2 32 -1 


value of a possible source- register(-reference) 


OperationsBttCode 


number 


0..21*M 


bitmask, which flags all possible operations 
between this Register_ID_dest / Register ! D_source 
-combination (p.e. 2 + 2 = 2*2 using same reg.'s). 
Values see CIT, calculation see fig. 19. 



St* 

For every register- or register-reference-modification of the same opcode -execution one entry is 
generated, which gives information about the register(-reference)-values before and after the 
execution and further information about the degree of changing and with it a hint to a possible 
operation and a possible source-register which were used. (Packed-, nibble-, or BCD -ope rations are 
not considered.) 

The last address-register is the stack-pointer. The last data-register is the "energy "-register. 

An address-register can be every register which value can be a pointer to memory which 

destination can be accessed using this register as a reference. 

Several registers can be modified simultaneous - therefore this additional 1:n table, where 
Register JD dest means the identity of the changed register. Sometimes many register(-references) 
could be the source for one operation - this quantum increases through the sum over all possible 
operations. 

Therefore the following tables identify the used opcode and the concerned register(s): 



OpCode-Learn-Tabie: [PL T - ascertained effect of the opcode using the concerning initial conditions] 
column: datatype value-range meaning: 



OpCode (PK) 


integer 


0..2 32 -1 


complete instruction, truncated if > 4 bytes 


IniConNr (PK) 


signed byte 


-31. .30 


number of used initial condition 


active ChkSum corrupt 


boolean 


1|0 


flag: checksum of active AC-program changed 


inactive ChkSum corrupt 


boolean 


no 


flag: checksum of inactive AC-program changed 


Exception Vect changed 


signed byte 


-128.. .0 


Register ID of the (first) overwritten exception-vector 


multiple Exc Vect chg 


boolean 


110 


more than one exception- vector was overwritten 


Processor Mode Changed 


boolean 


1|0 


flag: processor-mode changed (p.e. trace cleared) 


Number of Exception 


byte 


0..N+1 


exception-number [0: = no exception] (if 0 = exc: + 1 ) 


0 pCode Jeng t h_or Ju mp 


signed byte 


-128..127 


ElPyPCa after execution - BPjJ?Z u before execution 
-128=$FF=long back-jump, 127=$7F=long forward j. 


CCR before execution 


byte 


0..255 


CC-flags, which could cause a lump. 


Register_changed_BitCode 


number 


0..2 128 -1 


£ , 2 A ORT. Register ID dest V 0RT(opcode, IniConNr) 


RegistersourceBitCode 


number 


0..2 128 -1 


s^ORT.Register ID source V ORT(opcode,lniConNr) 


max_Operations_BitCode 


number(19) 


0..2 128 -1 


5* ORT. Calculation BitCode VORT(opcode, IniConNr) 


minOperationsBitCode 


number09) 


0..2 128 -1 


CORT.Calculation BitCode VORT(opcode.lniConNr) 


time of execution 


integer 


0..2 32 -1 


deci-seconds after {20.9.1994, 0:00:00,0 o'clock) 


cycles of execution 


byte 


1..255 


clock-cyctes the opcode-execution needed 


aim valuation 


signed byte 


-128..127 


aim-attaining-valuation using above initial-conditions 


gradient aim valuation 


signed byte 


-128..127 


-"-difference to CLT( n-1, IniConNr ). aim valuation 



Fig.6 
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OpCode-Base-Table: [QBT - ascertains the effect of the opcode-execution from the initial conditions] 
column: datatype value-range meaning: 



OpCode tPK) 


integer 


0..2 JZ -1 


complete instruction/ truncated if > 4 bytes 


Execution counter 


byte 


0..255 


number of the OLT-entries until now 


FatalErrorcounter 


byte 


0..255 


number 01 tne opcooe-causea Tatai errors unm now. 

UneCKoUm corrupt, cxcopuan_veuL_uiiaiiyeu, 
T rfl pp Rit rhAflrpH Processor Mode chanoed. and 
the exceptions without Divide -Error, Overflow. 


low error counter 


-— 

oyte 




number of divide- errors plus oye/7Zow-exceptions 


Jump longOp_probability 






probability that it's a long opcode or a jump 


avg OpCpde_Jump length 


signed uyie 


.100 107 


avpranp lenath of one ode or iumo 


upuoue ten unconiiririea 


Dooioan 


i in 


min. one divergence from above average exists 


avg cycles of execution 


byte 


1 


awpranfl hv QDcode-GXGCution needed clock-cvctes 


exec cycles unconfirmed 


Dooiean 


i n 

i . .\j 


min. one divergence from above average exists 


Register write_p rob ability 


siynea oyie 


t £.0,. 1 £- t 


nrnhnhititv oDcode writes into a reoister 




cinnnH hv/tp 


-128.. 127 


probability: opcode copies register 


Memorv write Drobabilitv 


signed byte 


-128. 127 


probability: opcode writes into memory 


Memory copy probability 


signed byte 


-128.. 127 


probability: opcode copies memory 


Reg to Mem probability 


signed byte 


-128.. 127 


probability: opcode copies reg. to adr.reg. -destination 


Mem to Reo. probability 


signed byte 


-128.. 127 


probability: opcode copies adr.reg. -destination to reg. 


Multi Reg write prob 


signed byte 


-128.. 127 


probability: opcode writes into more than one register 


Multi Mem write prob 


signed byte 


-128.. 127 


probability: opcode writes to many adr.reg. -destination 


Multi Reg to Mem prob 


signed byte 


-128.. 127 


prob.: opcode copies 22 reg. to £2 adr.reg. -destination 


Multi Mem to Reg prob 


signed byte 


-128. .127 


prob.: opcode copies 22 aor.reg.-oestinaiions to rev; 


all_Reg_dest_BitCode 


number 


0..2'^ B -1 


^OLT. Register changed Bitcode V OLT(OpCode) 


cut_Reg_dest_BitCode 


number 


0..2 128 -1 


COLT.Register changed Bitcode V OLT(OpCode) 


all Reg source BrtCode 


number 


0..2 128 -1 


^OLT.Register source Bitcode V OLT(OpCode) 


cut_Reg_source_BitCode 


number 


0..2 128 -1 


COLT.Register source Bitcode V OLT(OpCode) 


maxOperationBitCode 


number 


0..2 128 -1 


£"0LT.max Operation BitCode V OLT(OpCode) 


min_Operatk>n_BitCode 


number 


0..2 128 -1 


zTOLT.min Ooeration BitCode V OLT(OpCode) 


all_Operation_BitCode 


number 


0..2 128 -1 


^OLT.min Operation BitCode V OLT(OpCode) 


Cut wpciailUil DHUUUO 


numhpr 

1 IUI 1 IUCI 


0 2 128 -1 


/*niTmay Ooeration BitCode V OLTIODCode) 


max write value 


integer 


n 932 1 
U. .Z - 1 


mavimum nf all rlpQtinfltion-VflllJRS 
ilia AllllUi 1 1 <*l a*i ucaui la nvt i vaiuoa 


min write value 


integer 


0..2 32 -1 


minimum of all destination-values 


avg write value 


integer 




average over an oesLinauuii-voiuoa 


max write gradient 


integer 




maximum yrauieni oi ine cnaiiycu vaiuc 


min write gradient 


integer 




minimum graoieni oi ine cnuriyeu vaiue 


avg write gradient 


integer 




average graaiem ot ine cnanyco v<jiut? 


evaluated source Register 


signed byte 


-I ,U..l Z/ 


nnnn (-f n>r\A/J em ir^a.ranictar_tn fflftPT IjR T -f*\ZflllJflTIOO 
aSCerXainCO SOUlCv icUlalci fly lailC7> >✓ u » cvaiuouvi i. 


evaluated_source_NumReg 


signed byte 


-128, -1, 


-1 28 = LOB means source-constant; 0.. 1 27 means a 
TUnner source-reyisier iu r ituno — • iouci wui ^ vo< • ' 


evaluated dest Reoister 


signed byte 


-1, 0..12" 


ascertained destination-register after OBT-evaluatior 


evaluated_dest_Register2 


signed byte 


-1, 0..12" 


possible 2nd dest. -reg. after OBT-evaluation or flags- 
reg. (2 real dest.-reg. => flags-reg. not appreciated). 


evaluated Operation ID 


signed byte 


-1,0..63 


ascertained operation-ID (after OBT-evaluation) 


Confirmation counter 


byte 


0..255 


counter: same effects on other initial conditions 


max aim valuation 


signed byte 


-128.. 127 


max. valuability bf the opcode for aim-attaining 


avg aim valuation 


signed byte 


-128..127 


average valuability of the opcode for aim-attaining 


maxgradaimvaluation 


signed byte 


-128..127 


max. gradient of aim-attaining in relation to the by 1 
shorter opcode-combination of the last CBTO-1 ). 




signed byte 


-128.. 127 


average gradient concerning above -"- 



Fig. 7 

Datatypes: Boolean 1 Bit, BCD/Nibble 4 Bit, Byte/chard) 8 Bit, Word/short 16 Bit, DWord/lnteger 32 
Bit, QWord/number(19) 64 Bit, number/number(38,0) 128 Bit (38 digits £ 16 bytes), varchar2(N) 
string of variable length with max.N characters, long very long string with max<longDef) characters. 
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The following combination-tables are created dynamically - they have the same non-PK-columns, 
like the OBT respectively OLT respectively ORT, but for every additional number of combinations a 
further more opcode in the PK: 



Combmatlon-Register-Table: [CRT(i), i = number of opcodes in the combination, CRT(7) = ORTJ 
column: datatype value-range meaning: 



OpCode 1 (PK) 


integer 


0-2 32 -1 


opcode #1 (first of the combination) 


{for all OpCodes) (PK) 


all integer 


0-232-1 


{for all opcodes from #2 up to N-1 } 


OpCode N (PK) 


integer 


0-2 32 -1 


opcode#N (last of the combination) 


IniConNr (PK) 


signed byte 


-31.. 30 


current number of the used initial conditions 


Register ID dest (PK) 


signed byte 


0..127 


one by execution concerned destination-reg. (see RIT) 




signed byte 


-1..127 


-1 or one possible source-register (see RIT). 


(same non-PK columns 
like in the Opcode- 
Regis ter-Table. } 


see above 


see 
above 


same non-PK columns like ORT. 



Flg.8 



Combinations Learn-Table: fd T(i), i= number of opcodes in the combination, CL T( 1) = PL TJ 
column: datatype value-range meaning: 



OpCode 1 (PK) 


integer 


0-232-1 


opcode #1 (first of the combination) 


{for all OpCodes} (PK) 


all integer 


0-232-1 


{for all opcodes from #2 up to N-1 } 


OpCode N (PK) 


integer 


0-232.1 


opcode#N (last of the combination) 


IniConNr (PK) 




-31.. 30 


current number of the used initial conditions 


(same non-PK columns 
(ike in the Opcode-Learn- 
Table.) 


see above 


see 
above 


same non-PK columns like OL T. 



Fig.9 



Combinations-Base-Table: [CBT(i), i= number of opcodes in the combination, CBT(1) = OBT} 
column : da ta type value-range meaning: 



OpCode 1 (PK) 


integer 


0-232-1 


opcode #1 (first of the combination) 


(for oH OpCodes} (PK) 


all integer 


0-2 32 -1 


{for all opcodes from #2 up to N-1 } 


OpCode N (PK) 


integer 


0-232-1 


opoode#N (last of the combination) 


(same non-PK columns 
like in the Opcode-Base- 
Table.) 


see above 


see 
above 


same non-PK columns like OBT. 



"ado 

CBT(max.) = CPT = Combination-Plan-Table = point of origin of the outcoming program. 
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Prog ramming -aim and valuation-function tables: 
Aim-Solution-Table: [AST - solutions of all programming-aims] 



column: 


datatype 


value-range meaning: 


Aim ID (PK) 


short 


0..65535 


Identifier of the programming-aim 


Solution Nr (PK) 


byte 


0..255 


number of the solution-program 


aim Program 


long 


String 


opcode-combination of the solution here as a string 


Program length 


short 


1.. 65535 


length of the solution-program in doublewords 


cycles of execution 


integer 


1.. 232-1 


execution-time in clock-cycles of the solution-program 


used Registers BltCode 


number 


1..2 128 1 


bitcode of ail in the solution-program used registers 


used Operations Bitcode 


number 


1..2 128 -1 


bitcode of all in the solution-program used opcodes 


used aim Valuation Func 


signed short 


0..32767 


identifier of the used aim-distance valuation-function 


Fig.11 






Alm-Descriotion-Table: IADT - identification and description of programming-aim] 


column: 


datatype 


value-range meaning: 


Aim ID (PK) 


short 


0..65535 


Identifier of the programming-aim 


aim Description 


varchar2(32 


<32 Bytes 


description of the programming-aim 


used Processor Mode 


integer 


0-2 32 -1 


flags above CC | control-register-bits 


ail dest Register BitCode 


number 


L.2'28.! 


bitcode of all output-registers in this task 


all source Register BitCode 


number 


1..2 128 -1 


bitcode of all input-registers in this task 


unused Regiser BitCode 


number 


1..2' 28 -1 


bitcode of all registers which should not be used 


unu$ed_Operation_BrtCode 


number 


0..2 128 -1 


bitcode of all opcode-IDs which are not allowed to 
use in this task (default = $0000.0000:0000.0000) 


aim_implem8nt_solutions 


long 


String 


string of the AimJD's (words) of earlier solutions, 
which could be implemented here. 


aim fulfill valuation mode 


boolean 


on 


mode of aim-valuation: 0 = SQL ; 1 = machine-code 


aim fulfilled Flag Function 


varchar2(99 


<99 Bytes 


boolean aim-attained recognition-function as a string 


aim Valuation FunctionID 


signed short 


0..32767 


identifier of the valuation-function (see VFT) 



Fig. 12 



Functions-Identification-Table: [FIT - table of the basic sub functions used in the valuation-function] 
a.) for SQL-functions: 

column: datatype value-range meaning: 



Function ID (PK) 


signed byte 


-1..127 


identification-number of the basic function 


Function BitCode 


number(l9) 


0..26M 


bitcode of this basic function (only one bit is set) 


Function Name 


chaK5) 


5 Bytes 


function-name 


Function Type 


byte 


0..99 


0 = value, 1 = unitary, 2- binary, 3 = ternary, ... 


Function Flatten 


signed byte 


-127..127 


degree of flattening [+= steepening, - = flattening! 


Function Template 


varchar2(99 


<99 Bytes 


SQL function-template 


Function Description 


varchar2(99 


<99 Bytes 


optional description of the basic sub-function 



Fig. 13a 
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F.ID 


Function BftCode 


F.Name 


FT. 


F.F. 


Function Template 


Function Description 


0 


1 


NUM 


0 


0 


< following value > 


a constant number follow* 


1 


2 


ENGY 


0 


0 


ELT.energy after 


energy after execution 


2 


4 


GRAD 


0 


0 


E LT . energy jitter 
-ELT.energy before 


energy-gradient 


3 


8 


VALUE 


0 


0 


CLT(n). <columnNr> 


value in the following 
column-number (last row) 


4 


16 


EREG 


0 


0 


< EnergyRegister 1D> 


ID of the energy-register 


5 


32 


SGN 


1 


0 


SIGN( %s ) 


algebraic sign 


6 


64 


ROUND 


1 


0 


ROUND! %s, 0 ) 


rounded 


7 


128 


INT 


1 


0 


FLOOR{ %s ) 


truncated after dec. point 


8 


256 


ABS 


1 


0 


ABS< %s ) 


amount 


9 


512 


NEG 


1 


0 


-( %s) 


negation 


10 


1.024 


ADD 


2 


1 


((%s) + (%s)) 


addition 


11 


2.048 


SUB 


2 


-1 


( (%s) - (%s) ) 


subtraction 


12 


4.096 


MUL 


2 


4 


( (%s) * (%s) I 


multiplication 


13 


8.192 


DIV 


2 


-4 


( (%s) / (%s) ) 


division 


14 


16.384 


MOD 


2 


-2 


MOD( %s, %s ) 


rest of division 


15 


32.767 


SQRT 


1 


-8 


SQRT( %s ) 


square-root 


16 


$1.0000 


CBRT 


1 


-12 


POWER( %s, 1/3 ) 


cube-root 


17 


$2.0000 


MIN 




-10 


LEASK %s, %s ) 


minimum 


18 


$4.0000 


MAX 




-10 


GREATEST ( %s, %s ) 


maximum 


19 


$8.0000 


LN 


1 


-48 


LN( %s ) 


natural logarithm 


20 


$10.0000 


EXP 


1 


48 


EXPt %s ) 


nat. exponential-function 


21 


$20,0000 


LD 


1 


-32 


LOG( 2, %s ) 


logarithm on base 2 


22 


$40.0000 


POT 2 


1 


32 


P0WER( 2, %s ) 


2nd power of ... 


23 


$80.0000 


SIN 


1 


-64 


SIN( %s ) 


sine 


24 


$100.0000 


COS 


1 


-64 


COS( %s ) 


cosine 


25 


$200.0000 


TAN 


1 


127 


TAN( %s ) 


tangent 


26 


$400.0000 


ASIN 


1 


127 


ASIN( %s ) 


arc sine 


27 


$800.0000 


ACOS 


1 


127 


ACOS( %s ) 


arc cosine 


28 


$1000.0000 


ATAN 


1 


-127 


ATAN{ %s ) 


arc tangent 


29 


$2000.0000 


SINH 




40 


SINHI %s ) 


sine hyperbolic 


30 


$4000.0000 


COSK 


1 


50 


COSH( %s ) 


cosine hyperbolic 


31 


$8000.0000 


TANH 




-127 


TANH( %s ) 


tangent hyperbolic 


32 


$1.0000.0000 


LOG 


2 


-64 


LOG( %s, %s ) 


logarithm 


33 


$2.0000.0000 


POT 


2 


64 


POWERt %s, %s ) 


n-th power of ... 


34 


$4.0000.0000 


OR 


2 


1 


( (%s) | (%s> ) 


bitwise OR 


35 


$8.0000.0000 


AND 


2 


-1 


( (%s) & <%s) ) 


bitwise AND 


36 


$10.0000.0000 




2 


-127 


DECODEt %s, %s, 1.0) 


equal 


37 


$20.0000.0000 


LE 


2 


-127 


DEC0DE( GREATEST* %s - %s, 
0 ) r 0, 1,0) 


less-equal 


38 


$40.0000.0000 


GE 


2 


-127 


OECODEl LEAST( %s -%s, 0 ), 0, 
1,0) 


greater-equal 


39 


$80.0000.0000 


FRAME 


1 


-10 


GREATEST! LEAST! %s, + 127), 
-128) 


frame to signed-byte: 
max. = 127, min. = -128 


40 


$100.0000.0000 


BITS 


1 


-64 


[ \ a 7oS) + \Z a. 7bSJ/^ + & 

%s)/4 +(8 & %s)/8 + .... 


hiimKor r\f Kite in th(* 
nUniUci Ul LflLa ill Hie 

integer value 


41 


$200.0000.0000 


S__REG 


0 


0 


ADT.alfjsourceJiegi'sterS' 
BftCode 


bitcode of the source- 
register 


42 


$400.0000.0000 


D REG 


0 


0 


ADT.a// dest Registers BitCode 


bitcode of dest. -register 


43 


$800.0000.0000 


AIM_F 


0 


0 


VAL( ADT. aim Julfilled flag- 
Function ) 


result of the boolean 
aim-fulfilled-f unction 

















Fig. 13b 
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b.) for machine-code functions: 



Function ID (PK) 


signed byte 


-1..127 


identification-number of the basic function 


Function BitCode 


number(19) 




bitcode of this sub-function 


Operations BitCode 


number 


0..2 128 -1 


bitcode of the used opcodes in this function 


Registers BitCode 


number 


0..2 128 -1 


bitcode of the used registers in this function 


Function Name 


char(5) 


5 Bytes 


short notation of this sub-function 


Function Type 


byte 


0..99 


0 = value, 1 = unitary, 2 = binary, 3 = ternary, ... 


Function Flatten 


signed byte 


-128.. 127 


degree of function-flattening (1 = f(x) =x) 


Function OpCodes 


number 


1..2 12 «M 


sub-function in machine-code 


Function Description 


varchar2(99 


£99 Bytes 


optional description of the sub-function 



Fig.14a 






Oper.BftCodo 


Reg.BitCodt 


Func.Name 


FT. 


Func. OpCodes 


Function Descript 


0 


1 


$A000.4008 


< energy > 


FRAME 


1 


s.b. Fund 


prevent overflow 


1 


2 


;28800.0009 


< energy > 


SGN 


1 


s.b. Func.2 


signum 


2 


4 


$0000.0002 


< energy > 


NEG 


1 


<NF.G> 


negation 


3 


8 


$0000.0200 


< energy > 


MUL2 


1 


<SHLI> 


division by 2 


4 


16 


$0000.0400 


< energy > 


DIV2 


1 


<SHRI> 


multiplication by 2 


5 


32 


$0000.0100: 
4A00.8018 


(DO) | (en) 


ILOG2 


1 


s.b. Func.3 


mogarithm dualis 


6 


64 


$1000.COOO: 


(FP0)|<en> 


ISQRT 


1 


s.b. Func.4 


square-root 






0000.0000 










7 


128 




s. 1.4.2 


ICBRT 


1 


s.above 1 .4.2 


cube -root 


8 


256 


$0000.8000 


<en-1)|(en) 


MOV 


2 


<KOV> 


copying of one reg. 
before energy-reg. 


9 


512 


$0000.8000 


<erv1>|<8n) 


SWAP 


2 


s.b. Func. 5 


swap with reg. 
before energy-reg. 


10 


1024 


$0001.0000 


(en-1>|(en) 


ADD 


2 


<ADD> 


addition with -"- 


11 


2048 


$0002.0000 


<en-1>|(en) 


SUB 


2 


<SUB> 


subtraction of -"- 


12 


4096 


$0004.0000 


(en-1)|(en> 


MUL 


2 


<MUL> 


multiplied with -"- 


13 


8192 


$0008.0000 


(en-1)|(en> 


DIV 


2 


<DIV> 


division by 






















Fig. 14b 



Function: 


OpCodes of: (machine-code compilation of these mnemonics, here a Motorola-Exampte) 


Fund 


CMPM27,(E); JLE <+2> ; MOVI #1 27,(E> ; CMPI -1 28,(E) ; JGE ( + 2) ; MOVI #-128,(E 


Func.2 


TST(E); JGE (43); MOVI #-1.<E> ; JMP (+5) ; JGT ( + 3) ; MOVI #0,(E) ; JMP(+2); 
MOVI # + 1,<E> 


Func, 3 


MOVI #31, DO; BTST DO,(E) ; JEQ (+3) ; DJMPDO,<-2>; ADDI#1,D0; MOVE D0,<E) 


Func.4 


FILD (E) ; FSQRT ; FIST <E> 


Func. 5 


M0VE(E-1),-(A7) ; MOVE (E),(E-1) ; MOVE (A7) + ,(E) 




Fig. 14c 
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Table of the valuation-functions] 



column: 


datatype 


value-range meaning: 


Valuation Function ID (PKj 


signed short 


±32767 


identifier of the valuation-function {energyspecif. neg.) 


Valuatk>n_Function_Type 


chard) 




'E' = energy-valuation, 'A* = valuation for reaching 
closeness to programming-aim, ... (maybe further) 


Valuation Function Mode 


boolean 


on 


0 = SQL-mode ; 1 = machine-code mode 


Valuation Function 


varchar2(99 


<99 Bytes 


valuation-function for energy- or aim -attainment 


execution counter 


integer 


0-2 32 -l 


number of uses of this valuation-function 


used Functions BitCode 


number{19) 


0..2 64 -! 


BitCodes of all subfunctions 


Function ID Chain 


varchar2(99 


<99 Bytes 


chain of subfunctions (one byte = one Function ID) 


avg Func execution time 


integer 


0-2 32 -1 


average by val.-func.-execution needed dock-cycles 


boundary value counter 


integer 


0-2 32 -1 


counter incremented if the result is -1 28 or + 1 27 


low value counter 


integer 


0-2 32 -1 


counter incremented if the result inside ± 1 6 


Valuation_Function_value 


signed byte 


-128.. 127 


valuability of the valuation-function = SAC.Se/r"- 
Valuation Aim/Energy( Valuation Function, Values ) 



ID 


Ty 


M 




-1 


*E' 


0 


MAX[ MIN[ SBN( Energy flag'- Energy Reg° ) ■ S0RT( Energy Reg'- Energy Reg c ) 
-32-71 CLT(i). Register changed BitCode &( ! 2* Energy Register ID)} , +127], -128] 


0 


'A' 


0 


MAX[ M1N[ 16- 11 C\-T(\).Register_changed_BitCode & A DT. a fides t_R egister BitCode ) 
+ 16 /1 CLT(i). Register source _BitCode & ADJ. all _source Register _BitCode } 
+ 32- M>1. aim Jul filled Flag Functioni AimJD ) -CL7 (i). Processor Mode changed 
-&-CLT(i). cycles of execution -( CLl\S).active\inactive_ChkSum_corrupt) 
-( CLT(i). Exception _vect ^changed >0 ) -£ CL1 '(i). Number _ofjxception>0 ) 
CU{\).OpCode feng'th or jump > 4 or < 0 ), +1 27], -128] 




used F. BitCode 


Function ID chain 


ex.T 


bdy# 


k>w# 


F.Val 


0 


$189.0040.9836 


2,5; 2,15; 12; 4,22,3,11,35,40,1,32,12; 1 1 ; 39 


0 


0 


0 


0 


0 


SEE9.0001.3AAA 


3, 1 1 ,42,35, 1 , 1 6, 1 2; 3, 1 2,41 ,35,1 , 1 6, 1 2, 1 0; 
43,1,32,10, 3,7,11; 3,16,1,5,13.11; 3,3,11; 3,5,11 
3,5,5,10; 3,8,5,10; 3,9,1,0,37,1 1 ;3,9,1, 5,38,1 1;39 


0 


0 


0 


0 



Fig. 15b 



Status of the Artificial Consciousness: [SAC - status-values of the AC-progra m {only 7 row}] 
column: datatype value-range meaning: 



Programm StartDate 


timestamp 


da time 


date and time of the start of the AC-program 


actual Processor Mode 


integer 


0-2 32 -1 


flags above CCR | control-register-bits 


actual CPT index 


byte 


1..255 


CBT( wax{\)=actual CPT Nr ) = actual CPT 


CxT counter 


short 


1.. 65535 


number of creatinas of the dynamic CxT-tables 


Aims total 


short 


1.. 65535 


number of total programming-aims 


Aims soluted 


short 


0..65535 


number of solved programming-aims 


actual Aim ID 


short 


0..65535 


ID of the actual programming-aim 


Aim_Va!uation_Mode 


boolean 


on 


mode of the programming-aim-specific valuation- 
function: 0 = SQL-mode ; 1 = machine-code mode 


AimValuationFunctionID 


signed short 


0..32767 


actual VFT. Valuation Function ID referring the 
closeness to the programming-aim 


AimSerfValuationFunc 


varchar2 
(400) 


max.400 
Chars. 


PL/SQL-valuation-function referring the efficiency of 
the valuation-function 


Energy_ Va luationMode 


boolean 


0|1 


mode of the energyspecific valuation-function 
0 = SQL-mode ; 1 = machine-code mode 


Energy Valuation Func ID 


signed short 


-1.. -32768 


actual VFT. Valuation Function ID for energy-valuation 


Energy_Self_Valuation_Func 


varchar2 
(400) 


max.400 
Chars. 


PL/SQL-valuation-function referring the efficiency of 
the energyspecific valuation-function 


max Valuation Function 


signed short 


0..32767 


highest ID of all valuation-functions in the VFT. 


min Valuation Function 


signed short 


-1.. -32768 


lowest ID of all valuation-functions in the VFT. 



Fig. 16 
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Energy-Learn- Table: [EL T - appraises energyspeciftc actions in dependence of the used initial-conditions} 



Energyaction (PK) 


number 


r\ o 1 5B i 

0..2 X *°A 


max. 10 oyte opcooe-comDinaiion ot ine aciiun 
wnicn cnangea ine erttsryY-reyioier. 


IniConNr (PK) 


signed byte 


-31.. 30 


number of the used initial condition 


Energy before 


integer 


0..2 32 -1 


energy-register before execution 


Energy after 


integer 


0.. 23 2 -1 


energy-register after execution 


min Operations BitCode 


number 


0..2 128 -1 


bitcode of the probably used opcodes. 


max Operations BitCode 


number 


0.2 128 -1 


bitcode of the possibly used opcodes. 


Register changed BitCode 


number 


1..2 128 -1 


bitcode of the by action changed registers. 


Register source BitCode 


number 


1..2 128 -1 


bitcode of the probable source-registers. 


used cycles of execution 


short 


1.. 65535 


needed clock cycles for the enerayspecif ic action 


Energy valuation 


signed byte 


-128.. 127 


result of the actual VFT.Energy valuation Function 






-1.. -32768 


used energyspecific valuation-function 



Fig .17 



Energy-Base-Table: [EBT - evaluation of the energyspecific actions] 
column: datatype value-range meaning: 



Energyaction 



(PK) 



number 



0..2 128 -1 



max. 1 6 byte opcode-combination of the action 
which changed the energy-register. 



Execution counter 



byte 



0..255 



number of the ELT-entries until now. 



FatalError counter 



byte 



0..255 



number of the occurred fatal errors: 
fatal errors correlate the columns 3-7 of the above 
learn-table. except Divide-Error or Overfiow-Exc. 
number of Divide-Errors or Overflow -Exceptions 



low Error counter 



byte 



avgEn ergy after 



integer 



0..255 
0..2 32 -1 



ail_Reg_dest_BitCode 



number 



0..2 128 -1 



average energy-value after the action 



^ELT. Register changed Bitcode V ELT(OpCode) 



cut Reg dest BitCode 



number 



0..2 128 -1 



CELT.Register changed Bitcode V ELT(OpCode) 



all_Reg_source_BttCode 



number 



0..2 128 -1 



SELT. Register source Bitcode V ELUOpCode) 



cutRegsourceBitCode 



number 



0..2 128 -1 



max Operation BitCode 



number 



0..2 128 -1 



CELT.Register source Bitcode V ELT(OpCode) 



iTELT.max Operation BitCode V ELT(OpCode) 



minOperationBitCode 



number 



0..2 128 -1 



al l_0 perationBitCode 



number 



0..2 128 -1 



CELT. min Operation BitCode V ELT(OpCode) 



jELT.min Operation BitCode V ELKOpCode! 



cut_Operation_BitCode 



number 



0..2 128 -1 



CELT. max Operation BitCode V ELT(OpCode) 
maximum of all energy-values after energy-action 
minimum nf nil cmAmv-valiies after enerav-action 



max write value 



intege 



0..2 32 -1 



min write value 



integer 



0..2 32 -1 



minimum of all energy-values after energy-action 
average of all energy-values after energy-action 



avg 



write value 



integer 



0..2 32 -1 



max write gradient 



integer 



0..2 32 -1 



min write gradient 



integer 



0..2 32 -1 



maximum gradient of the changes energy-register 



minimum gradient of the changes energy-register ## 



avg write gradient 



integer 



0..2 32 -1 



average gradient of the changes energy-register 



equal value probability 



signed byte 



-128.. 127 



probability of equal result of energyspecific action 
average value-gradient of this energyspecific action 
probability: gradient is constant 



avg Energy gradient 



signed int 



±231 



equal Gradient probability 



signed byte 



•128.. 127 



avg cycles of execution 



short 



1 ..65535 



average needed clock cycles for this action 



avg Energy valuation 



signed byte 



-128.. 127 



Valuation Function ID 



signed short 



-1.. -32758 



result of the actual VFT.Energy valuation Function 
ID of the used energy-valuation-f unction 



Fig. 18 
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3.2 Flowchart of the AC-Program: 

3.2. 1 CxTO) value assignments: 
ORT & CRTfi) value aasmgments: 

ORT.Register ID dest := log 2 ( g;r(QLT.Register changed Mask), of the regarded changing ) 

ORT.Register ID source := Register IP( C° ), rf ORT.calculation code > 0, otherwise^ 

ORT. value before change := value (Register ID test), before opcode-execution 

ORT.value after change := value (Register ID dest), after opcode-execution 

ORT.gradient if signed := MAX| MINI ORT.value after change - ORT.value before_change, + 127], -128] 
ORT.gradient if unsigned := MAX[ MIMI ORT.value after change - ORT.value before change, +1271, -128] 
ORT.Operation_BitCode V(RagsVRags 0 >&8MV'-V°)&&[ NF&&(V ( ° <0) 1 1 ZF&&(V,°=0) ] 
+ 2•[{V l ' = -V l 0 )&&V-(V=V <, )] +4[(V, , = -V t 0 )&&V(V=V°)3 + 8-[{V,' = 0LB)&&V-(V'=V°)] 
♦ 1 6.[(V,' = V,° +0LB)&&V(V'= V°)1 + 32.[(V,' = V,° -OLB )&&V(V'= V°)] + 64 [(V l * = V,° 0LBI&& V(V= V°)3 
+ 128[IV,'=V I V0LB)&W"(V , =V°)] + ^^ 

+ 2 10 -[(Vr = V, °/2-OLB)&&V-(V-=V 0 )] + 2' 1 *[(V,' - V, 0 | OLB)&&V(V=V 0 )] + 2' 2 .[(V,' = V,°&0LB)&&V"(V=V o )] 
+ 2 13 .<RaQ^Rags 0 )&&V{V'^ 1 
+ 2 14 .(Fla9sVFIaas 0 )&&V(V^V°)&W NF&&(V|° <0LB)| |ZF&&(V ( ° = 0LB)] + 2 15 *[(V,' = C,°)&&V"(V'=V 0 )] 
+ 2 1 ^(V t ' = V l °+C l 0 )&^-(V'=V^ 

+ 2 19 4(V l , = V, o /C ( o )&W*(V t =V o )] + 2 20 [(V I , = V l o %C 0 )&&V-^ 
+ 222.[(v | , = V,V2 c °)&aVTV , =V 0 W^ 

+ 2 25 .(Rags^Hag3 0 )&&V(V'.V*)&&|(ZF=1)&&(2 A C, 0 hV, 0 )| |(ZF-0)&&l(2 A C l o | V,°) ] 

♦ 2 26 .(Fla9sVRags°)&&V(V , =V°|&&[ NF&&(V,° <C,°H |ZF&&(V,° =C,°) ] 
+ 2 27 -[(IP' < IP°)| |{IP , >IP c +4)]&&(Rags , «Rags°)&&V(V , =V°) 

+ 2 2a [(IP' < IP°)| |{IP' >tP d ^4)l&&(Ftegs , =Rags 0 )&&VtV , -V°)&&(NF&IVF|lrlF&VF) + ...VJcc(CCR) 
+ 2 4 °.{[(IP' <IP°)||(IP'>IP°+4)]^ 

+ 2 4 M( IP' = IP°±0LB)&&((SP) = IP o JiMHays'-Ragi^MVTV'-n 

+2 42 'U IP* =-4(SP) )&&(Rags'-Rags 0 )&&V(V , =V 0 ) + 2 43 *[(V| , ^V|°)&&(! other_kiteger_Operation_BitCode)l 
+ 2 44 |(V F VV F °)&&(! other Jloa^ 

+ 2 4 9.[(V F , =V F o -C l o )&&VlV , =V o )] + 2 50 4(V F , = Vp°.C l o )&W-(V , =V^ 
+ 2 52 .(FlagsVRags 0 )&&V(V , =V°)&&[ NF&&(V F ° <C,°)| |ZF&&(V F ° = C,°J] 

♦ 2 53 -l (V F ' = 1 .0) 1 1 (V F l = 0.0) | | (V F ' = x) 1 1 (V F ' = e) ]&&V(V'=V°) 

♦ 2 54 .[(v F ' = -v F ° )&&(v p ° < ojaaviv-v 0 )] + 2^ [( v F * = c F ° )&&v-(V'=v°)] 

+2 s M(Vp'=V F 0 +C F °)&&VlV'=V 0 H^^ 

+ 2 58 *[(V F ' = V F 0 C F 0 )&^ 

+ 26MV F , -sin(V F °)]&&V7V'=n^^ 

+ 2 64 .[<V F ' = V f °-2*Vm °)&&V-(V'=V°)] + 2 65 -[(V F ! - V F . r log 7 (V F °)&&V"(V'=V 0 )] 

+ 2 6B .(RagsVR3g S °)&&V(V=V 0 )&&[ NF&&(V F ° <C F °)| |ZF&&(V F ° -C F °)I + 2 67 [(V, f = C S °)&&V-(V'=V°)] 

+ 2 6a -[(V $ '=C| 0 )&&V"(V , -V°)] + ... . where V' = value_afte r_change (->Flags), V°=vafueJ>efore_change 

C°=value(RegisterJD_source). Here has to be checked over all Reg ister_ID_source(eq. kind). 

Though equal Register-ID's in the PK several bits can be set. [p.e. because 

4 = 2 + 2 = 2«2=SHL(2) = ...3 , 

Fig. 19 

OLT & CL T(i) value assingments: . 

OLT.Processor_Mode_Changed : = T{ EFIags*/Sfy & ! 5'2 A CCR_Flags ) > 0 1 1 

ORT.value after change( Register ID of a special-register ) . 

OLT.aim valuation := VFT.Aim_Valuation_Function( SAC.Aim_Valuation_FunctionlD, ORT.xxxxx, 
Registers_changed_BitCode, Registers_source_BitCode, min_Operations_BitCode, 
max Operations SitCode, used cycles of execution, ... ) — 

CLT(n). gradient aim valuation := CLT(n).aim valuation - CLT(n-1 ).aim_valuation 

all other column-assignments are declared adequate in the OLT-description in fig. 6. 

Fig.20 
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OBT 3 CBTfi) value-assinaments: 

OBT.Execution counter := Execution counter + 1 

OBT.FatalError_counter : = FatalError_counter +(0 < OLT.Numberof Exception * Divide_Error, 

Overflow ) | [ OLT.active_ChkSum_corrupt 1 1 OLT.inactive_ChkSum_corrupt 1 1 

QLT. Exception vect changed 1 1 OLT.Processor Modechanged ) 

OBT.Jump_longOp_probability := MAX[ MIN[ Jump_probability + (OLT.OpCode_length_orjump < 0 ) 

+ {OLT.OpCode length or jump>4), + 127], -128] 

OBT.avgOpCodeJumpJength := <execution_counter*avg_OpCode jumpjength 

+ akt.0pCode jump length) / (execution counter* 1) 

OBT.OpCodeJen_unconfirmed := OpCodeJen_unconfirmed 1 1 ( avg_OpCode_length * 

act.OpCode length ) 

OBT.avg_cycles_of_execution : = ( executioncounter * avg_cycles_of_execution + 

act. cycles of execution ) / (execution counter + 1) ___ 

OBT.exec_cycles_unconf irmed : = exec_cycles_unconf irmed 1 1 (avg_cycles_of_execution * 

act.cycles of execution ) 

OBT.Register_write_probability : = MAX| M!N[ Register_write_probability +2*[ ( min.Reg.ID < 

0RT.CoJumn_ID_OLT < max.Reg.ID )&& ORT.va!ue_before_change * ORT.value_after_change ] - 

1, +1271,-128] _ 

OBT.Register_copy_probability := MAX[ MIN[ MIN( Register_copy_probability +2*[ ( min.Reg.1D ^ 

ORT.ColumnJD_OLT < max. Reg. ID )&& ORT.value_before_change * ORT.value_after_change 

&&( min.RegJD < ORT.Column ID source ^ max.Reg.ID ) ] -1, + 127], -128] 

OBT.Memory_write_probability := MAX} Mlffl Memory_write_probability + 2*[ { min.Adr.Reg.lD < 

ORT.Column_ID_OLT <> max.Adr.Reg.ID )&& ORT.value_before_change * 

QRT.value after change 1 -1 , +1 27], -1 28] 

OBT.Memory_copy_probability := MAX[ MIN[ Memory_copy_probabifity + 2*[ ( min.Adr.Reg.lD < 
ORT.ColumnJD_OLT < max.Adr.RegJD )&& ORT.value_before_change * 

ORT.valuejafter_change &&( min.Adr.Reg.ID £ ORT.Column_ID_source < max.Adr.RegJD ) ] -1, 

+ 1271, -128] 

OBT.Reg_to_Mem_probability := MAX[ MIN[ Reg_to_Me improbability +2*1 ( min.Adr.Reg.ID <, 

ORT.ColumnJDOLT < max.Adr.RegJD )&& ORT.value_before_change * ORT.value_after- 

change &&( min.Reg.ID £ ORT.Column ID source < max.Reg.ID ) ] -1, +127], -1281 

OBT,Mem_to_Reg_probability := MAX| MIN[ Mem_to_Reg_probability +2*[ ( min.RegJD £ 

ORT. Column JDOLT <. max.RegJD )&& ORT.value_before_change * ORT.value_after_change 

&&( min.Adr.Reg.ID <, ORT.Column ID source ^ max.Adr.RegJD I ] -1, + 127], -1281 

OBT.Multi_Reg_write_prob : = like in Register_write_probability , but with min.2 appropriate 

ORT.Column ID QLT -entries. __ , - 

OBT.Multi_Mem_write_prob : = like in Memory_write_probability , but with min.2 appropriate 

ORT.Column ID QLT -entries. . 

OBT.Multi_Reg_to_Mem_prob : = like in Reg_to_Me improbability , but with min.2 appropriate 

ORT.Column JD QLT + Column IDsource -entries. 

OBT.Multi_Mem_to_Reg_prob := like in Mem_to_Reg_probability , but with min.2 appropriate 

ORT. Column_lD_OLT+ Column ID source -entries. . 

OBT.xxx Reg_source|dest BitCode: see table-description , 

OBT.xxx calculation BitCode: see table-description . 

OBT.max write value : = MAX( max write_value, QRT.value after change ) 

OBT.min write value := MIN( min write value, QRT.value after change ) 

OBT.avg_write_ value : = I execution counter * avg_wrrte_value +• ORT.value_after_change ) / 

(executioncounter+1 ) _ — 

OBT.max_write_gradient := MAX( max_write_gradient, ORT. value_after change - 

QRT.value before change ) . 

OBT.min_write_gradient := MINI minwritegradient, ORT.valueafterchange - 

QRT.value before change ) . 

OBT.avg_write_gradient := ( execution_counter * avg_write_gradient + ORT.value_after change - 

QRT.value before change ) / (execution counter + 1) 

OBT.evaluated_source_[Num]Register := probability-functioni xxx_Reg_source_BitCode, 

confirmation counter ) 
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OBT.evaluated dest_Register[2] := probability-functionj xxx_Reg dest BitCode, confirmation-counter ) 
OBT.evaluated_Operation ID := probabifity-functionj xxx Operation BitCode, confirmation-counter) 
OBT.Confirmationjjounter := Confirmation_counter + ex/sf( equivalent OLT+ORT-ev/j try with tower 

IniConNr ) . . 

OBT.max aim valuation := MAX( max aim valuation, OLT.aim valuation ) 

OBT.avg_aim_valuation := ( execution_counter * avg_aim_valuation + OLT.aim_valuation ) / 

(execution counter + 1 } m 

CBT(n).max_grad_aim_valuation : = MAX( CBT(n)max_aim_vatuation, CLT(n).aim_valuation ) 

- CBT(n-1 ). max aim valuation. _ 

CBT(n).avg_grad_aim_valuation := ( execution counter * CBT(n).avg_aim_valuation 

+ CLT(nF.aim "valuation ) / (execution counter* 1) - CBT(n-1).avg grad aim valuation 

Rg.21 

3. 2.2 EL T and BBT value-assignments: 

ELT. max Operations BitCode := OLT.max Operations OpCode ' 

ELT.min Operations_BitCode := OLT.min Operations OpCode 

ELT. Register changed. Bit Code := OLT.Registers changed BitCode 

ELT.Register_source_BitCode := OLT. Registers source, BitCode 

ELT.Energy_Valuation :- VFT.Energy_valuation_Function( SAC.EnergyValuationFunctionID, 

Energy after, Energy J>efore, Registers_changed_BitCode, Registers_source_BitCode, 

min Operations BitCode, max_Operations BitCode, used cycles of execution, ... ) 

ELT. Valuation Function ID := for calculation of Energy Valuation used VFT.Valuation Function ID 
EBT.avg_Energy_after := ( execution_counter • avg_Energy_after + ELT.Energyafter ) I 

(execution counter + 1 ) . : 

EBT.equal value probability := equal value, probability + 2 ( avg Energy after = ELT.Energy after ) -1 
EBT.avg_Energy_gradient := ( execution_counter * avg_Energy_gradient + ELT.Energy_after - 

ELT.Energy before ) / (execution counter + 1) 

EBT.equal_gradient_probabilrty := equal_gradient_probability + 2*( avg_Energy_gradient = 

ELT.Energy after-ELT. Energy before ) -1 „ 

EBT.xxx_Operations | Registers BitCode see table-description „ 

EBT.avg_cycles_of_executk>n := ( executioncounter • avg_cycles_of_execution + ELT.used_cycles- 

of execution ) / (execution counter + 1 ) ; , 

EBT.avg_Energy_ Valuation := ( execution_counter • avgEnergyJ/aluation + ELT.Energyvaluation > 

/(execution counter+1) 

Fig.22 



3.2.3 Definitions needed to read the flowchart: 



directives I denotes a directive or a short sequence of directives. 



< condition fulfilled ? ) Yes: branches horizontally, No: continue below. 



contlnufng-label) denotes a label to or from another part of the flowchart. 



block of directives denotes a block of earlier defined directives. 



In the flowchart because of the complexity not all things are described until the smallest detail, 
but the fundamental functionality is presented clear and comprehensible. 

Self-evident things like closing a database-cursor or cofilling not explicit mentioned but existing 
table-columns (which do not need a special algorithm) are not performed additionally, because the 
meaning of these columns is already declared in 3.1.2 an their assignment-formulas in 3.2.1 or in 
3.2.2. 

In the flowchart means 'generate ORTentry and actualise OBJ' what is already shown in the 
value-assignments in fig. 19-21. 



Fig.23 
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3.2.4 AC-flowchart: 

a J Initial Preparations: 
| save all register- values, I 
| save all original exception- vectors. | 



initialise processor by deleting all breakpoints, clear all flags in the control-register and clear all 
flags in the high word of the status/flags-register. 



| create AC-database and load (respectively calculate) the initial table-values. 



[ capture all exception-vectors to own hand)er~ 



capture exceptions, which load additional data to the supervisor-stack, by a special exception- 
routine which considers the additional data. 



Misuse one exception- vector- routine to switch to the supervisor-mode and trigger this 
exception (processor switches into supervisor-mode and continues on this vector-address 
where the further flow of program is. 



Pop the onto the stack loaded EFIagSu/Statusregister^ so, that when it's loaded the 
Tracea/Trap n -flag is set (to be in the single-step-mode then). 



Pop the EIPn/PQt/ on the stack so, that when it's loaded by the return from supervisor-mode 
instruction, the processor continues on the memory where the test-opcode was located. 



Prepare initial test-values in ICT, which are loaded into the registers for the opcode-test so, 
that all register-values and destination-values of the address-registers have got different 
values. . 



| Initialise the DWord-opcode generator- counter to -1 - SFFFF.FFFF 



| Initialise the IniConNr-counter to -32. 

Flg.24a 



bj Base-Learning: 
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I increment opcode-generator-counter by 1 and set lniConNr=-32 ] 



< did opcode become U$0000.0000 twice ? )-►( goto action-learning (Fig.24c) ) 

I increment IniConNr by iH < — I DB-comm it | 

< IniConNr > 30 ? > 

TT 



Set all register- values and addressregister-destination-values to ICT.Register_value(lniConNr), 
write 8 times NOP after test-opcode-address in memory (behind is the capture- routine for 
Trac e,i/Trap TC -Flag cleared) and write the generated test-opcode above the test-address. 



Execute return from supervisor-mode: The EFIags^/SRw-testvaiue is now loaded from the 
supervisor-stack and single-step is switched on. B\P n fPC u is loaded from the supervisor- 
stack and the in its vector-address located test-opcode is executed. 


Analyse: 


After the test-opcode-execution the effects of its execution are 
analysed and the analysis-result is stored.: 



I 

< Did a Non-Trace-Exceptiqn occur ? )-» 
i 

( Did at all no Exception occur ? )-¥ 



set 01 T. Number pi ' Exception, Fiags- 
before execution, etc. f actualise OBT 



set OL T. Processor Mode changed, 
actualise OBT. 



inside single -step-routine - analysis of the opcode-execution-effects: 

Z3 



[compute the CheckSum of the AC-program and the CheckSum if its inactive copy 



( CheckSum of the active AC-Prg. changed ? >- 



set 017. active ChkSum corrupt r jump to 
the equivalent position of the inactive code 
and the corrupt code; actualise OBT. 



< CheckSum of the inactive AC-Prg. changed ? )- 



set inactive ChkSum _corrupt-F\ag, repair 
inactive code; actualise OBT. 



( Was an exception-vector overwritten ? >-> 



set the exception vectors again, write the Ni 
of changed one into OLT. Exception Vector- 
changed, generate QRT-entry; actualise OBT 



Compare the EIP n /PC u on the stack (pushed through Trace) with the address of the test- 
opcode and set OpCode length or jump to the difference (framed by min.-1 28,max.l27j^ 



< E\Pj/PC u was not increased b y I. A bytes ?) -► 1 actualise jump-specific OBT-columns 

ir ~~ 



If opcode was shorter than DWord, increase generator up to $<byte>FF.FFFF if length 
was byte, on word-length to $<word>.FFFF and on 3-byte-opcode to $<Word-Bvte>FF. 

ir 



I Compare the trace-bit on the to stack pushed ERagSrr/SBiv with the original test-value. 



(-Did a register-value icL Flags change 7)- 



Loop over all register: 



Generate ORT+OLT-entries and actualise 
OBT. If the ■energy'' -register-value changed, 
generate ELT-entry and actualise EBT. 



( Did the dest. -value of an adress-reg. change? )-* 
Loop over all aar.-reg.: | 

I 



Generate ORT+OLT-entries and actualise 
OBT. 



Fig. 24b 
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cJ Double-OpCode-Acting: 

( Begin of Double-OpCode-Acting [after Base Learning - Fig. 24b]) 

I 



OBT-E valuation: with probability-functions evaluated source JNum]Reg[ister] is derived from 
OBT.xxx_Reg_source_BitCode , evaluated } _dest_Register[2J derived from xxx Reg dest BitCode and 
evaluated Operadtion ID is derived from xxx Operation BitCode (considering confirmation counter). 



I Define the last data-register as "energy" -register and set to an average value. | 

| Open 1 st Cursor over the OBT. "I 



I Fetch next row fr om the 1st OBT-cursor. 

I ^ 

( Triple Opcode-Pfenning <Fig.24c) )<-( Fetch 1 empty (1st opcode processed) ? ) 

/ JumpJongOp probability > 0 or Y [ADT. unused ^Register BitCode(Aim ID) \ 
\ 3fOB7\cutsou^eR 

( Execution_cqunter / OBT OpCqdeJFatalError_counter (opcode 1) < 5 ?) - 



1 


Open 2nd Cursor over the OBT. 


i 


i 


U 


Fetch next row from the 2nd OBT-cursor. 
— l 


i 



{ Fetch2 empty (2nd opcode processed ? > 3 

_ / Jump fongOp probability > 0 or T[A D T. unused Register BitCodefAim ID) \ 
\ S(OBtcut__source ffegjg/rCo^ ] (OpC.2) > 0? / 

-^ (Execution counter / OBT OpCode FatalError counter (opcode2) < 5 ? ) 

jr - 

| initialise lniConNr=-32 I 



lniConNr+ + I 
— 1 ^ 



- {IniConNr > +30? ) 



Initialising and execution using the initial conditions of the corresponding I 

IniConNr, like during the base-learning, but now for the double-opcode. j 

j 

Same procedure like in the analysis-block of the base-learning (Fig. 24b), but | 

analysis-results now stored into CRT(2), CLT(2) and CBT(2). II 



T 



decrement "energy" -register by 1. I 



( Is the "energy * -register in the middle or high range ? ) 



J 



Select and execute an EBT. Energy specific jaction which has a high 
anergy action valuation and a high confirmation counter. 

4* 



Analysis-block like above. 



Fig.24c 
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d.) Tripie-OpCode-Ptanning: 
( Begin of Triple Opcode -Planning [after Double-Opcode-Actions] ) 



CBT-Evaluation: with probability-functions evaluated _source_[Num]Reg[ister) is derived from CBT(2). 
xxx_Reg_source_BitCode , evaluated _dest_Register[2] derived from xxx_Reg_dest_BitCode and 
evaluated Operadtion ID is derived from xxx Operation BitCode (considering confirmation counter). 

| Open 1st cursor over the CBT(2) 1 



| Fetch next row from the 1st cursor out of CBT(2) 



] 



( Quad-Opcode-Planning )<- ( Fetch 1 empty (1st opcode processed) ? > 

/ JumpJongOpjprobability > 0 or 1? [ADT. unused ' Register BitCode(AimJD) \ 
\ &(OCT(2).cut_sourceJ^egBitCode\pBT(2)xutdest 0 ? / 

( Execution ^counter / CBT(2). OpCrie_FatalError counter (opcode 1) < 5 ? ) - 



I 


Open 2nd cursor, but now over the OBT 


I 


i 


U 


Fetch next row from the 2nd cursor out of OBT. 


I 



< Fetch2 empty Jreat opcode processed) ? ) 

/ Jump JongOp probability > 0 or Y[ADT.unused Register _BitCode( Aim ID) \ 
\ &(OBT.cutj>ourceJlegJLitCode\OBT.cut^ >0 ? / 

- ( Execution counter / OBT. OpCode FatalError counter < 5 ? ) 

4r 



initialise lniConNr = -32 

i 



IniConNr* ^ 



-< IniConNr > +30 ? ) 



Initialising and execution with the initial conditions of the corresponding 
IniConNr like during the double-opcode-actions, but now for the triple-opcode 

4< 



Same procedure like in the analysis-block of the double-opcode-actions 
(Fig. 24c), but analysis-results now stored into CRT(3), CLTOI and CBT(31 




Decrement "energyVegister and same tryings to increase it like during the 
double-opcode-actions with equivalent valuation-analysis of the action. 



Fig,24d 



Procedure for higher combinations analogous, using CxT(n), where n = sum_of_opcodes. 
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Bezeichnung: 



Verfahren zur Generierung einer einfachen Form kunstlichen Bewufttseins im Computer zur 
Befahigung selbsttatig planender Erstellung von Maschinencode-Programmen und deren 
5 Ausfuhrung zur L6sung beliebiger gesteilter Programmieraufgaben 



I n h a 1 1: 

1. Beschreibung 

10 1.1 Aufgabenstellung und Stand der Technik 

1.2 Herteitung der Realisierbarkeit und Definition kunstlichen Bewufttseins 

1.2.1 Philosophische GrundQberlegungen 

1.2.2 Realisationsansatz zur Generierung von kunstlichem BewuBtsein 

1 .3 technische Lehre zur Generierung kunstlichen Bewufctseins 
15 1 .3.0 Definition der verwendeten Abkurzungen 

1.3.1 Verfahrensweise zur Generierung von kunstlichem BewuBtsein mit einfachen 
Worten 

1.3.2 Datenbank des KB-Wissens anlegen 

1 .3.2.x Beschreibungen der KB-Tabellen 
20 1 .3.3 das System in den vorbereitenden Anfangszustand bringen 

1 .3.4 Basis-Lernen aus den Ausfuhrungen aller OpCodes 

1 .3.4.1 OpCode generieren und ausfuhren 

1 .3.4.2 Analyse der OpCode-Auswirkung und Speichern der Ergebnisse 

1 .3.5 Realisierung der Grundbedurfnisse 

25 1.3.5.1 Realisierung kunstlichen Schmerzes 

1.3.5.2 Realisierung kunstlichen Hungers 

1 .3.6 Planen nach den Kriterien des Be wertungs systems 

1.3.7 Entwicklung des dynamischen Bewertungssystems 

1.3.8 Selbstbewu&twerdung, Reproduktion und Evolution 

30 1 A Programmieraufgabenstellung und Beispiele der Zielerreichung 
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2. Patentanspruche 

3. Zeichnungen 
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Fig.5-10: OpCode- und Kombinations-Tabellen; ORT, OLT, OBT; CxT(i) 
45 Fig. 1 1, 72:Programmierziel-Tabellen: AST, ADT 

Fig. /3-/5:Bewertungs-Tabellen: FIT, VFT 

Fig. 16: KB-Statuszeile: SAC 

Fig. 17-18: Energiespezifische Tabellen: ELT, EBT 
3.2 Flufcdiagramm des KB-Programms: 
50 3.2.1 Wertezuweisungen der OxT bzw. CxT(i): Fig. 19-21 
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1. Beschreibung: 

1.1 Aufgabenstetlung und Stand der Technik: 

5 Allein in Deutschland fehlen auf dem Gebiet der Software- Entwickiung z.Z. 80.000 Mitarbeiter 
und die Entwicklungs-Aufgaben werden immer icomplexer. 

Bislang werden Programme nach gegebener Aufgabenstellung von Software-Entwicklern konzi- 
piert und programmiert 

Zur Erleichterung der Prog ram mierung gibt es bislang "Wizards", die mittels Dialog-Fenstem 
10 nach interaktiver Eingabe von Daten des Benutzers grundlegende Teiie des Source-Codes nach 
fest vorgegebenen Schemata erstellen. 

Ferner werden auch firmenspezifische Skripte geschrieben, die mittels Auslesen von Daten aus 
ASCII-Files einfache stetig wiederkehrende Teile von Sourcecodes generieren. 
In jedem Fall muB der Benutzer jedoch das erstellende Skript selbst schreiben und vomer die 
15 auszulesenden Daten generieren bzw. im Falle von "Wizards'' vorher in Dialogfenstern benutzer- 
definierte Eingaben machen und nach der Erstellung des Rahmen-Quellcodes die eigentliche 
Funktionsweise der Anwendung selbst ausprogrammieren. Danach muB noch der Source-Code 
in Maschinencode compiliert werden, bevor er ausgefOhrt werden kann. 
Lemfahig sind solche Programme jedoch nicht. 

20 

Auf dem Gebiet der Kl gibt es neuronale Netzwerke / fuzzy Logic die zwar Expertensysteme 
bilden kannen, die auBere sensorische Reize aufnehmen und lernfahig in den "Neuronen" dann 
ihre Reaktion darauf entscheiden, also eine Art lernfahige Regelkreise bilden, jedoch kfinnen sie 
weder planen noch Maschinencode generieren und ausfuhren. 

25 

In 20 W (pat) 12/76 wurde die Generierung kunstlichen BewuBtseins mit rein elektronischen 
Mitteln iAneinanderreihung von Kameras und Monitoren) versucht - dieses Verfahren hier hat 
damit jedoch uberhaupt nichts zu tun. 

30 Mittels meinem Verfahren wird im Computer eine einfache Form von BewuBtsein erzeugt, das 
anfangs zwar ziellos willkurlich Handelt, jedoch aus den Wirkungen seines eigenen "Verhaltens" 
lernt, urn so, nachdem es die Wirkungen aller mftglichen Handlungen kennt, spater pianend 
selektiv Einzelhandlungen aneinanderzuketten, z.B. um ein vorgegebenes Ziel zu erreichen. 
Jeder Einzelhandlung entspricht hierbei eine Zahl, die, wenn man sie als OpCode (Maschinen- 

35 code), also als direkte Prozessorsteuerungsanweisung, ausfuhrt, entweder einen Fehler (Excep- 
tion) erzeugt, Oder eine Veranderung (z.B. der Registerinhalte) bewirkt. 

Das System selektiert mittels geeigneter Analyse- und Bewertungsverfahren Codezusammen- 
stellungen, die dann das gegebene Programmierziel erreichen. 

40 

1 .2 Herleitung der Realisierbarkeit und Definition kunstlichen BewuBtseins: 

1.2. 1 Philosophteche GrundQberlegungen: 

(... sind normalerweise kein Bestandteil einer Patentbeschreibung, jedoch fur die Darle- 
45 gung der Realisierbarkeit hier unerlaBiich) 

Ware die Voraussetzung des menschlichen BewuBtseins eine Art "Beseelung\ die zwischen 
Zygote und Geburt stattfande, k6nnte man sie aufgrund von Gedankenexperimenten ungefahr 
lokalisieren: 

50 Wurde man gedanklich den Kopf abtrennen und die Halsschlagadern mit sauerstoff- und nfihr- 
stoffreichen Blut versorgen, wSre das BewuBtsein sicher im Kopf. 

Wiirde man nun das Gehirn bis auf die kiinstliche Versorgung vdliig isolieren, ware zwar auf 
herkammliche Weise kein InformationsfluB zwischen dem Individuum und der Umwelt mehr 
mdglich, das " I ch- BewuBtsein" wflre aber sicher noch vorhanden. 
55 Jetzt kann man noch gedanklich die hinteren und seitlichen GroBhirnlappen fur Sehen, Hfiren, 
Riechen, Schmecken, Gleichgewicht, Sprache und das Kleinhirn abtrennen und es ware nichts 
weiters verloren. 



-3- 



Bei den vorderen Hirnlappen verlbre man die Moglichkeit mit vortiandenem Wissen zu rechen 
und bei einigen oberen Hirnteilen ginge Erinnerung verloren, aber das Grund-lchJ>in ware immer 
noch vorhanden, 

=> Wenn es eine Art "Seele" gSbe, lage sie am oberen Ende des Stammhirns. 

5 

Unter Berucksichtigung der gleitenden Evolution hatten dann Primaten aber auch eine "Seele". 
Und andere SSugetiere auch und alle anderen Tiere auch; und Einzeller auch; und Pflanzen 
auch; und somit auch jede einzelne Zelle des menschlichen Kdrpers selbst. 
=> Es fehlt eine "BewuGtseins-" bzw. "Beseelungsgrenze*. 
10 => Jede Zelle unseres Kdrpers mtiGte eine eigene Seele haben (die evolutionare Spezialisierung 
zur Nervenzelle ist, wie auch bei den prenatalen Zellteilungen, flie&end). 
=> Es gibt keine "Seele". 

=> BewuGtsein entsteht im laufe der Evolution zwingend selbsttattg. 
=> im "toten" MolekOI der DNA liegt der Bauplan zur Generierung von BewuGtsein. 
15. => BewuQtsein entsteht dutch die Bewertung von eigenen Tatigkeiten und deren Au swirkungen, 

mft der Reflexion der Bewertungsergebnisse auf das sich anpassende B ewertungssystem. 

Wenn zur Generierung von BewuGtsein keine "Seele" notwendig ist. sondern nur das komplexe 

"Programm" der DNA, dann ist BewuGtsein auch durch ein komplexes reflexives Computer- 

Programm generierbar. 



1.2.2 Reaiisationsansatz zur Generierung von kQnstlichem Bewu&tsem: 

Das Handeln aller, auch der einfachsten Individuen dient zur ErfQIIung ihrer Grundbedurfnisse. 
25 Diese Grundbedurfnisse sind: 

a. ) kein Schmerz : = kein Angriff auf 's System und 

b. ) kein Hunger := kein drohender Energieverlust 

Ein komplexes Programm, im dem diese Grundbedurfnisse modelliert sind, und das frei Handeln 
30 kann und in der Lage ist, wie ein Kind aus seinen Handlungen reflexiv zu lernen, was seine 
Handlungen bewirken und ob seine Handlungen seine Situation im Bezug auf seine Grund- 
bedurfnisse verbessern oder verschlechtern, baut ein Bewertungssystem auf, plant dann seine 
Handlungen aus dem Erlernten zur Verbesserung seiner Situation und erlangt so BewuGtsein. 
Scannt es auch einmal seinen eigenen Code, probiert aus, was seine Code-Abschnitte bewirken 
35 und erkennt deren Zusammenhang, erlangt es sogar Selbst-BewuGtsein, und kann nicht nur 
seinen Code reproduzieren, sondern seinen Code bei der Reproduktion auch bewuGt verandern 
und verbessern, also eine Evolution aufgrund seiner Erkenntnisse beginnen. 

40 1.3. technische Lehre zur Generierung kunst lichen BewuBtseins: 

1.3.0 Definition der verwendeten Abkurzungen: 

Die Programmierung funktioniert auf jedem Computer mit jedem beliebigem Prozessor und 
45 jedem beliebigem Betriebssystem. Die mit n indizierten Abkurzungen sind fur die Motorolla- 
Prozessoren MC680xO spezifisch, die mit n indizierten fur die Intel-Pentiums und y -indizierte 
kennzeichnen den PowerPC-RISC-Prozessor: 

8q. = aquivalentle(s)] 

50 ASR^ = Adress Space Register 

BAT^ = BAT-Registers 

BC = BitCode: jedes Bit entspricht einem Code und es sind Codekombinationen zulassig. 

CCfy = Condition-Code-Register i = Flags: Extension, Negativ-, Zero-, Overflow-, Carry-) 

CISC = Complex-lnstructionSet Computer (z.B. lA^-und MC^) 

55 CPU = Central processing Unit = Prozessor 

CRy, = Condition-Register (CR 0..7) 

CR^ ** Control-Register 
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CTR^ = Count-Register 
DABRy, = Data Ad r ess Breakpoint Register 
DAR^ = Data Adress Register 
DB = DatenBank 
5 DEC^ = Decrement-Register 
DR3. = Debug-Register 

DSISfy, = DSI Status-Register zeigt den Grund fur DSI- und Alignment-Exceptions an. 
EA = Effective Adress (direkter Speicherzugriff ohne Register) 
EAR^ = External Access Register 
10 Rseg* = Segment Register: CS; SS; DS. ES, FS, GS 

EFIags* = 32-Bit Register mit den System-Flags: IDent-, VirtuaHnterrupt Pen ding-, VirtuallnterruptFlag- 
AlignmentCheck-, Virtual8086Mode-, Resumeflag-, NestedTask, InputOutputPrivilegeLevel, 
OverflowFlag, DirectionFlag, InterruptEnabieRag, TrapFlag, Signffag, ZeroFlag, 
Auxiliary/Align-CarryFlag, ParityFlag, CarryFlag. 
15 eip^ = Extended Instruction Pointer (£ PC^) 
ER = Entity Relationship (Datenbankmodell) 
ESP* = Extended StackPointer {^USP^) 

Exc. = Exception^ ffOevideError, #DeBug, NMI IRQ, #BreakPoint, #OverFlow, #BoundRange 
exceeded, #UD (Invalid Opcode), #NM (device not available), #Double£ault, invalid 
20 #TaskSwitch, Segment #NotPresent, #SS (StackFault), # Genera I Protection, 

#PageFault, #MF (Floating Point-Error), #AlignmentCheck, #MachineCheck. 
Exception^. Reset, BusError, AdressError, invalidOpCode, Div/0, CHK, TrapV, 

Privilege Violation, Trace, Interrupts, Traps. 
Exception^ System-Reset, Machine-Check, DSI, ISI, Ext.lnterrupt, Alignment, 
25 Program, Floating-Point unavailable, Decrementer, System Call, Trace, Floating- 

Point Assist. 
FFT = fast Fourier-Transformation 
FK = Foreign Key einer ER-Datenbanktabetle 
FPR^, = Floating-Point Register 0.. 31 
30 FPSCr\,= Floating-Point Status and Control Register 
GB = GigaBytes = 2 30 Bytes 

GPR = General Purpose Registers; beim. Pentium*; EAX, EBX, ECX, EDX; ESI, EDI, EBP; ESP; 

EIP und beim PowerPC^ GPR 0..31 und bei Motorola^ die Daten- und Adress-Reg. 

IA = Intel-Architecture 
35 IRQ = Interrupt-Request 

KB = Kunstliches BewuBtsein 

kB - KiloBytes = 2 10 Bytes 

Id = Logarithmus dualis = log 2 

LR^ = Link-Register 
40 MB = MegaBytes = 2 20 Bytes 

MSRV = Model Specific Register 

MSR^ = Machine State Register 

NMI = Non-Maskable-lnterrupt (hochster Interrupt) 

NOP = NoOperartion-OpCode [Maschinencodebefehl ohne Wirkung (aulier IP^/PC A + + )] 
45 OLB = OpCode Lower Byte = letztes Byte im OpCode 

PCu = Programm-Counter ( = Pointer auf 1 .Byte der Speicherstelle, an der sich der Prozessor 
im Programm gerade bef indet, vor der dortigen OpCode-Ausfuhrung) 

PK = Primary Key einer ER-Datenbanktabelle 

PVR^ = Processor Version Register 
50 RISC = Reduced-lnstructionSet Computer (z.B. PowerPC^) 

RT^ = Befehl: Return from Exception (Ifidt SR und PC vom Supervisor-Stack) 

SDRI^ = SDR1 -Register 

SPRG^ - SPRG0..3 

Sfy = Statusregister (Flags^ Trace-, Supervisor-, +lnterrupt-Maske: l 2 h \q, 4-CCR-Flags) 
55 SF^ = Segment Registers: CS, DS, SS, ES, FS, GS 
SR^ = Segment Registers 
SRR^ = Save/Restore-Register of Machine-Status 
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SSP^ = Supervisor-Stackpointer (A7 im Supervisor- Modus) 

TBz - Time Base Facility: Time-Counter 2 64 -1 

TR* = Table-Register: GDTR, IDTR, LDTR, TR 

USP^ = User-Stackpointer (Aderessregister A7 im User-Modus, A7* im Supervisor-Modus) 

5 = = entspricht 

$ = Beginn einer Hexadezimalzahl 

£ « Ergebnis des bitweisen AND uber alle folgenden Werte [ = & V 2 & .... & V n ] 

E = Ergebnis des bitweisen OR uber alle folgenden Werte [=V 1 | V 2 | .... | V n ] 

r = Anzahl der gesetzten Bits im folgenden Wert [ = (1 &V) + (2&V)/2 + (4&V)/4+ ....] 

10 V* = fur alle anderen ... (nur V£ fur alle...) 



1.3. 1 Verfahrensweise zur Generierung von kunstiichem Bewu&tsein mit einfachen Wort en: 

15 Ein Computersystem erlangt BewuBtsein, wenn das aktive Programm, bei dem alle Exception- 
Vektoren abgefangen sind, und Grundbedurfnisse modelliert sind, folgenderma&en verfahrt: 
Generiere eine Zahl und verwende sie als OpCode ( = Operation-Code = Maschinencode-Befehl|; 
fuhre ihn aus, werte aus, was er bewirkt hat und speichere die ermittelte Wirkung der Aus- 
fGhrung. Fahre so mit alien Zahlen-*OpCodes mit vielen representative n Anfangsbedingungen 

20 {Register-Werte und Adressregister-Verweisinhalte) fort. 

Benutze dann so die gespeicherten OpCodes, die keine oder nur selten eine Exception verur- 
sachten und werte aus, ob deren Ausfiihrung die eigenen Grundbedurfnisse erfullen, oder ihnen 
abtraglich sind. 

Kette dann die OpCodes aneinander, die die eigene Situation nicht verschlechterten, und werte 
25 die Wirkung dieser Code-Kombinationen aus, und speichere deren Wirkung. 

Plane so Codekombinationen, die das Wohlbefinden bzgl. der Grundbedurfnisse {Modellierung 
siehe 1.3-5) erhohen bzw. fur das gegebene Programmierziel von Bedeutung sein konnten. 



30 1.32 Datenbank des KB-Wissens ante gen: 

Damit das Erlernte des KB-Programms persistent bleibt und die groften Datenmengen komfor- 
tabel erreichbar sind, wird eine relational Datenbank mit den Tabellen und deren Relationen 
gemaB 3.1 angelegt; zwecks Zug riff sbesch leu nigung und Speicherplatzersparnis aquivalente 
35 PKs als Cluster, und es werden zwecks Erhohung der Zugriffsgeschwindigkeit fur bendtigte 
Non-PK-Sparten wertere Indexe angelegt. Das ER-Diagramm zeigt Fig.l . 

Je nach Prozessor und wieviele 32-Bit-Befehle dieser hat, kann die Datenbank sehr groG und die 
Zugriffsgeschwindigkeiten entsprechend langsam werden. Deshaib eignen sich RlSC-Prozes- 
soren eher fur das KB-Programm als CISC-Rechner. Aber auch die CISC-Maschinen, wie die der 
40 IA, benutzen nur bei relativ wenigen Befehlen mehr als 24-Bit, weshalb man mit uber mehrere 
Festplatten gestribeten Tabellen und zusatzlichen Index-Festplatten und mit erhohtem "Verges- 
sen" bei ineffizienten Befehlskombinationen ebenfalls sehr gut arbeiten kann. 
Auf das Speicherplatzproblem wird unter 1.5 eingegangen. 

45 1.3.2. 1 Die Register-ldentifikations-Tabelie [RIT - Fig.2J: 

In der RIT werden die Qaten jedes Prozessor- Registers initial eingegeben: Jedes Register enthSIt 
eine Identifikations-Nummer ein zugewiesenes Bit im BitCode ein Zeichen zur Beschreibung des 
Register-Typs, eine laufende Nummer dieses Register-Typs und optional eine Beschreibung des 
Registers. Das Register der Flags (EFIags*/Sfy) hat die Register-ID 0. Die Exception-Vektoren 

50 sind zwar meist keine Register, sondern direkte Adressen im Speicher - urn diese wichtigen 
Vektoren ebenfalls identifizieren zu konnen, erhalten sie Redister-IDs mit negativem Vorzeichen, 
die der Exception-Vektornummer entsprechen [wenn Exception-Nr. 0 nicht Reset, sondern eine 
echte Exception ist, urn 1 verschoben - dann: Register JD- -(ExceptionNr+ 1)]. 
In Fig. 2b ist IQr das Beispiel Motorola dargelegt, wie die RIT aussehen konnte. 
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1.3.2.2 Die Qperations-ldentifikations-Tabelle [OIT - Fig A]: 

Wie in der RIT die Register, bekommen in der OIT die wichtigsten Operationen eine Identifi- 
kationsnummer und ein Bit im BitCode zugeordnet. 

Der Operation JType ordnet die Operation in Gruppen ein, die in Fig.4c beschrieben sind. 
5 Die Operation Mnemonic (braucht nicht exakt zu sein) und die optionale Operation Description 
beschreiben, um was fur einen Befehl es sich handelt. 

1.3.2.3 Die Anfangsbedingungs-Tabelie HOT (initiai conditions/ - Fig. 31: 

Da fur gleiche OpCode-Ausfuhrungen, je nach Anfangsbedingungen, unterschiedliche Wirkung- 
10 en auftreten konnen, werden in dieser Tabelle representative Anfangsbedingungen vorgegeben. 
Fur jede Anfangsbedingungsnummer (hier -31. .+30) werden fQr alte positiven Register JDs ein 
Sample von Anfangsbedingungen z.B. nach der in Fig. 3b vorgestellten Funktion generiert. 
Jedoch nur fur aiie Register, die mathematisch verwertbare Zahlen enthalten konnen, wie 
Daten-Register, Adress-Register-Verweise und die Adressierung darunter [wg. -(Adr.Reg.)], 
15 Floating-Point-Register und sonstige spezielle Rechen-Register (z.B. MMX). 

Mit Adress-Registern ISBt sich zwar auch rechnen, jedoch haben sie immer Werte die an 
Speicheradressen verweisen, an denen dann die vordefinierten Verweis-lnhalte stehen. Somit 
konnen die Anfangsbedingungen fur die Adressregister allenfalls zyklisch durch die Testwerte in 
den Verweisen laufen. 

20 Das Status^/EFIagvRegister hat in den ho her en Bytes immer die gleichen Anfangswerte aus 
S AC. actual _Processor Mode. Bei den ConditionCodes im untersten Byte konnen jedoch die 
Anfangswerte variieren. Mit den Control-, Debug- und Maschinenstatus-Registern, sowie 
sonstigen Spezialregistern wird anfangs ebenfalls kein Unfug getrieben und sie werden immer 
auf die gleichen, Default-Werte gesetzt. 

25 

1.3-2.4 Die QpCode-Register-Tabeile IORT - Fig.SJ: 

Fur jedes durch die OpCode-Ausf uhrung verfinderte Register der aktuellen Anfangsbedingungen 
wird in einer Schleife iiber alle moglichen Quellregister ermittelt, durch welche mdgliche 
Operation mit welchem Quellregister der Wert im Zielregister entstanden sein k6nnte. Fur jede 
30 zutreffende Quell-Ziel-Register-Kombination wird ein Tabelleneintrag generiert (bei unitSren 
Operationen ist Register JD source und fur jede zutreffende Operationsmflglichkeit das 
zugeh6rige Bit entsprechend der OIT im Operations ^BitCode gesetzt. Wie alle Feider der ORT 
berechnet werden, ist [n Fig. 5 beschrieben. Fig. 19 enthfllt die Wertezuweisungs-Algorithmen. 

35 1.3.2.5 Die OpCode-Lem-Tabelle [OLT - Fig.6]: 

Die OLT stellt eine Zusammenfassung der Auswirkungen des aktuellen OpCodes unter den 
verschiedenen verwendeten Anfangsbedingungen dar. 

In den ersten 6 Spalten werden Informationen uber fatale Auswirkungen dieses OpCodes 
gesammelt. Dann kommt die Differenz des Programmzahlers nach der OpCode-Ausf uhrung zum 
40 Wert davor und nun die Condition-Codes, die einen Sprung ausgel&st haben kannten [redundant 
ICT. Register _ Value(RegisterJD = 0)] . 

Danach kommen in Register changed BitCode und Register jsource BitCode die Bits aller 
moglichen Ziet- und Quell-Register aus den zugehorigen ORT-Eintrfigen und in maxOperation- 
BitCode und min_Operation_BitCode die bitweise geOfleten und geANDeXen BitCodes der 
45 ORT. Operations BitCode -Eintrage. 

Die Dauer und der Zeitpunkt der OpCode-Ausf uhrung werden gespeichert und in aimvaluation 
wird entsprechend VFT. Valuation _Function[ ADT .aim_ Valuation FunctionID ) bewertet, wie 
wertvoll der OpCode unter diesen Anfangsbedingungen fur die Programmierzielerreichung war 
(Wertezuweisungen nach Fig. 20). 

50 

1.3.2.6 Die OpCodeBasis-Tabeffe IOBT - Fig.7): 

Die OpCode-Basis-Tabelle beschreibt die ermittelte Gesamtwirkung eines OpCodes unter alien 
verwendeten Anfangsbedingungen. In Fig. 21 ist dargelegt, wie die Auswertung (Fullen der 
Spalten) erfolgt, um einen "Steckbrief" des OpCodes zu erstellen. 
55 Die OBT enthalt das Resumme aller Ausfuhrungen dieses OpCodes und ist spater beim 
zielgerichteten planen von Codekombinationen wichtig. 
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1.3.2.7 Die Kombinations-Register-Tabellen [CRT(i) - Fig. 8]: 

Die Kombinations-Register-Tabellen werden dynamisch angelegt und entsprechen der der ORT, 
mit dem Unterschied, daS hier die Wirkungen von OpCode-Kombinationen anarysiert werden. 
CBT(l) = OBT, CBT(2) hat einen OpCode mehr im PK, CBT(3) hat 3 OpCodes im PK, u.s.w. 

5 

1.3.2.8 Die Kombinations-Lern-Tabetlen (CLT(i) - Fig. 9): 

Hier gilt das gleiche analog der CRT(i). Die CLT(i) geben die Wirkung der OpCode-Kombination 
bei den verwendeten Anfangsbedingungen wieder. Jetzt gewinnt auch das Feld CLT(i). gradient- 
_aim_valuation an Bedeutung. Wflhrend es noch bei der CLT{1) = OLT identisch aimyaluation 
10 ist r enthait es bei den CLT{i>2): CLT(i}.aim_yaluation - CLTti-D.aimjfaluation (Fig. 20 unten). 

1.3.2.9 Die Kombinations-Basis-Tabel/en ICBTti) - Fig. 10]: 

Die CBT(i) geben folglich das Resummfc der Wirkung der OpCode-Kombination wieder. Die 
Wertezuweisungen erfolgen nach Fig. 21. Die gerade hdchste CBT(n) ist die CPT (Kombinations- 
15 Pian-Tabelle » Entstehung sort des Lbsungsprogramms). 

Ergibt ADT.aimJullfi!!ed_Flag_Function(CPT-PK) = 1 (TRUE), wurde gerade ein Losungsprogramm 
der gesteilten Programmieraufgabe gefunden, und es wird in der AST eingetragen. 

1.3.2.10 Die ZielldsungS'Tabelle [AST (aim solution) - Fig. 1 1]: 

20 Die AST enthait fur jede gestellte Programmieraufgabe die Ldsungsprogramme, deren Programm- 
ISngen, die AusfOhrungszeiten und die je benutzten Register und Operationen. 

1.3.2.11 Die Ziel-BeschreibungS'TabeUe [APT (aim description) - Fig. 12]: 

Die ADT ordnet jedem Programmierziel eine Indentifikationsnummer zu, eine Kurzbeschreibung, 
25 die BitCode-Kombinationen der zu verwendenden Quell- und Ziei-Register, die Register und 
Operationen, die im Losungsprogramm nicht verwendet werden sollen, fruhere Ldsungspro- 
gramme, die mitverwendet werden kdnnten und eine Funktion, die TRUE ausgibt, wenn die 
OpCode-Kombination fur die Ein- und Ausgabe Register eine Losung der gesteilten Aufgabe dar- 
stellt, sowie eine Identifikation der Ziel-AnnSherungsfunktion der VFT (u.a. v. o.g. aim Jutfitled- 
30 Flag Function abhangig), die die Zielnahe der akt. OpCode-Kombination (-CPT-PK) bewertet. 

1.3.2.12 Die Funktion -/den tiflkations-Tabel/e [FIT - Fig. 13, 14]: 

In der FIT werden Teilfunktionen, die fur die Zusammenstellung der Energie-Bewertungsfunktion 
verwendet werden konnten, zur VerfOgung gestellt. 
35 Sie wird in 2 Variationen vorgestellt: 

a. ) fOr die Erstellung einer dynamischen Bewertungsfunktion in SQL, 

b. ) fur die Erstellung einer dynamischen Bewertungsfunktion in Maschinensprache. 

Der veranderiiche Aufbau einer Bewertungsfunktion ist In SQL viel einfacher zu bewerkstelligen, 
jedoch sind die AusfOhrungszeiten entsprechend langsam und es muft nach jeder Zusammen- 
40 stellung neu geparsed werden. 

Zukunftig soil auch die Bewertungsfunktion gleich in Maschinencode zusammengestellt werden. 
Das auch hat den Vorteil, daB das KB-Programm manche geloste Programmierziele als FIT- 
Teilfunktionen fur die Zusammenstellung der Bewertungsfunktion weiterverwenden kann. 

45 1.3.2.13 Die Bewertungs-Funktions-Tabelle [VFT (valuation f.) - Fig. 15]: 

In der VFT liegt das dynamische Bewertungssystem im Bezug auf das eigene "Wohlbefinden" 
(Energie-Register) und der Programmierzielnahe. 

Die VFT. Valuation _Function{ Type = 'E\ SAC.EnergyValuationFunctionJD ) bewertet energie- 
spezifische Handlungen und die Valuation J=unction{ Type='A\ SAC.Aim_Valuation_FunctionlD ) 

50 die Programmierziel-Erreichungsndhe. 

Die VFT. Function JDjOhain enthait die Verkettung der Function-ID's, also die Teitfunktions-Ausfuhr- 
ungs-Reihenfolge: Hier bewirkt NUM, daS der nachste Wert eine Byte-Zahl ist, VALUE. daS der 
nachste Wert die LfdNr der CLT(n)-Spalte ist, der ein Wert entnommen wird, EREG die RegisterJD 
des Energie-Registers, S/D REG der Wert aus der ADT.all_source/dest_Registers_BitCode und AIM_F 

55 das Ergebnis aus der ADT.aim_furfilled_Flag_Function. Die unitSren Operationen wirken auf das letzte 
Ergebnis und die binSren auf die letzten 2 Ergebnisse aus der FunctionJD Chain. 
Bei jeder Anpassung, Erweiterung oder sonstigen Verbesserung dieser Bewertungsfunktionen 
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wird die Valuation Function JD incrementiert und ein neuer Eintrag mit der veranderten 
Valuation Function generiert und alle Bewertungsfunktionen in ihrcr Effizienz neu bewertet: 
VFT .Valuation ^Function j/alue - SAC. Energy/Aim set f_vatuation_Func(..J], urn einen Effizienz- 
Gradienten als Referenz fur weitere Verbesserungen zu haben. 
5 Die Funkttonsweise des dynamischen Bewertungssystems ist unter 1 .3.7 beschrieben. 

1.3.2.14 Die Statuszeiie des KB-Proqramms [SAC (state artificial consciousness) - Fig. 16]: 
Diese Tabelle hat keinen Key und nur einen Eintrag. Er enthait die Status informationen des KB- 
Programms und zwei Selbstbewertungs-Funktionen, die Effizienz der Energie- und der 
10 Zielannaherungs-Bewertungsfunktionen der VFT anhand ihrer gelieferten Ergebnisse bewertet. 
Diese Selbstbewertungsfunktionen werden, im Gegensatz zur Energie- und Zieinahe- 
Bewertungsfunktion, vom Programm selbst nicht mehr verandert, kflnnen jedoch vom Benutzer 
angepaRt werden. 

15 1.3.2.15 Die Energie-Lern-Tabelle fELT - Fia. 17]: 

In der ELT werden Daten uber alle energiespezifischen Handlungen der akt. Anfangsbeding- 
ungen, also (iber alle OpCodes und Code-Kombinationen, die das latzte Datenregister betreffen. 
gesammelt. 

Die Wertvolligkeit der energiespezifischen Handlung wird nach ELT. Energy ^valuation = 
20 VFT.Vaiuation_Function{SAC.Energy_Vafuation_Func_iD) bewertet. 

1.3.2.16 Die Energie-Basis-TabeJie [EBT - Fig. 18]: 

Ahnlich wie in den CBT(i), werden in der EBT die Auswirkungen einer energieandernden Code- 
Kombinationen, als Resuming alier Anfangsbedingungen, gesammelt. 

25 

1.3.3 Das System in den vorbereitenden Anfangszustand bringen: 

Um das System spSter wieder ohne neues booten in den urspninglichen Zustand versetzen zu 
30 konnen, mussen einige Pointer ( = Zeiger = Adressen) gesichert (zwischengespeichert) werden. 
Danach werden die Exception-Vektoren mit eigenen Abfang-Routinen belegt, da das System 
anfangs Zahlen willkGriich als Maschinencode generiert und ausfuhrt, obwohl viele dieser 
Zahlen als OpCode unzulSssig sind Oder aufgrund der gerade gewahlten Anfangsbedingungen 
Fehler veairsachen. Systemabstiirze wfiren die Folge, wenn man nicht alle Exception-Vektoren 
35 abfinge. 

Will man das bewuGtseingenerierende Programm laufen lassen, mufi man also, im Falle, da& es 
als einziges Programm im Computer laufen soil: 

a. ) das Multitasking abschalten, in dem man dieses entweder mit einer Betriebssystemroutine 
40 disabled oder indem man die IRQ-Maske des Prozessors auf NMt setzt. 

b. l alle System-Exception-Vektoren sichern. 

c. ) alle Sytem-Exception-Vektoren des Prozessors auf eigene Behandlungsroutinen umlenken. 
OQ* er wenn man es spater einmal neben anderen Programmen und vielleicht auch weiteren k.B.- 
Programmen parallel laufen lassen will: 

45 a') die eigene Task-PrioritSt etwas erhohen. 
b*) alle Task-Exception-Vektoren sichern. 

c'lalle Task-Exception-Vektoren des KB-Programms auf eigene Behandlungsroutinen umlenken. 

d. )das Statusregister^ (^EFIags^ und den User-Stackpolnter sichern. 

50 e.) die Werte der anderen Adressregister und die der Datenregister sichern. 

f. ) die Werte der Segment-, Control-, Debug- und Spezialregister sichern. 

g. )manche Exception-Vektoren auf besondere Abfangroutine setzen, die berucksichtigt, dafc 

zusStzliche Daten (z.B. bei Adressfehler: zusatzlich Zugriffsadresse + Opcode) auf den Super- 
visor-Stack geladen werden. 
55 h.) Privilege-Violation-Exception- Vector auf besondere Abfangroutine setzen. 

L) einen Trap-Vektor auf eine Routine setzen, bei der im Supervisor-Modus fortgefOhrt werden 
soil. 
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j.) diesen Trap ausfuhren (CPU schaltet sich jetzt in den Supervisor-Modus und macht ab dieser 

Trap-Vektoradresse weiter). 
k.) Trace-Exception-Vektor auf eigene Trace-Routine zur Wirkungs-Analyse setzen. 
U Flags des ersten Word auf dem Supervisor-Stack so setzen, daB beim Laden des SR vom 
5 SSP das Trace-Flag und die IRQ-Maske->NMI gesetzt werden (bei Motorola ist das #$8700). 

denn wShrend des fotgenden Basis-Lernens soli noch kein Interrupt moglich sein. 
Siehe hierzu Fig. 24a, 

10 1.3.4 Basis-Lemen aus den AusfOhrungen atier Op Codes: 
1.3.4.1 OpCode generieren und ausfOhren: 

a. )32-Bit-Zahl als OpCode generieren, angefangen bei $0000.0000, im weiteren Veriauf immer 

um 1 hochzahlen [dabei kann man von vorn herein die OpCodes uberspringen, die offen- 
15 sichtlich Unfug machen wurden (siehe BitCodes des CPU-Befehlssatzes)]. 

b. )Daten- und Adress-Register, sowie die AdressRegister-Verweislnhalte und die Verweis- 

Inhalte ein DWord darunter auf vordefinierte Testwerte laden und die ConditionCodes in 
EFIags^CR^ loschen, 

c. )Den generierten OpCode an die Teststelle im Speicher schreiben. Hinter der Teststelle muR 
20 noch mit ausreichend NOP-OpCodes (oder besser mit Nullen, wenn diese der Mnemonic "ORI 

#0, Reg.O" entsprechen) aufgefullt werden, da es sich um einen langen Befehl handeln 
kdnnte und auch der Fall der Trace- Bit-Loschung mitberucksichtigt werden muB (dahinter 
steht die Trace-Bit-Cleered Abfangrouttne). 

d. )Supervisor-Stack-lnhalt so setzen, daft beim Rucksprung aus dem Supervisor-Modus das 
25 Statusregister mit gelbschtem CCR, IRQ-Maske auf NMi, Trace-Bit gesetzt und Supervisor- 

BittMaske] geloscht, geladen wird und das dahinter befindliche Langwort die Test-Adresse 
darstellt. Rucksprung aus Supervisor-Modus (RT^) ausfuhren: das EFIags^Status-Rgister,, 
wird mit o.g. Werten initiiert und der IP^/PC^ mit der Testadresse geladen und der an der 
Teststelle befindliche OpCode ausgefuhrt. 
30 • Ist jetzt eine Exception (aufcer Trace) aufgetreten, wird die Exception kurz grafisch 
angezeigt und bei der Generierung des nachsten Opcodes fortgefuhrt. Diesen OpCode 
kann das Individuum vergessen. [Achtung: bei manchen Exceptions tritt wegen Trace 
eine Kombination des Exception-Handlings auf.3 

• Tritt weder Trace, noch eine andere Exception auf, wurde das Trace-Bit geloscht (sollte 
35 bei Einzel-OpCodes nie auftreten) und die hinter der Teststelle befindliche Abfangroutine 

wird ausgefuhrt. 

• Bei Trace-Exception (Normalfall) wurde ein benutzbarer OpCode generiert, dessen Aus- 
fuhrungs-Auswirkungen jetzt analysiert werden mussen. 

40 1.3.4.2 Analyse der OpCode-Ausw/rkung und Speichern der Ergebnisse: 

a. ) Das EFIagSfc/Status-Register^ und die Daten- und Adressregister, sowie Adressregister- 

Verweisinhafte und die Verweisinhalte des DWords vor den Adressregistern und den User- 
Stackpinter zur Analyse speichern. 

b. )Uberprufung der eigenen Maschinencode-CheckSum des aktiven KB-Programms und der 
45 Checksum der inaktiven Kopie im RAM (je ohne Test- OpCode-Speicherste lie): Bei Check- 

Sum-Anderung hat sich das Programm bei der Ausfuhrung "vertetzt" (Programmteile selbst 
uberschrieben). Dann das entsprechende Corrupt-Flag in der Tabelle setzen. Bei Verletzung 
der aktiven Version in die inaktive Kopien springen, dann den Code vergleichen und die 
korrupten Bytes durch Code der unverletzten Version ersetzen. 

50 c.)Die Supervisor-BitMaske des gesicherten User-Stackpointers auf Stack priifen: War der 
Prozessor vor Ausfuhrung der Exception im Supervisor-Modus (obwohl er bei der Test- 
OpCode-Ausfuhrung im User-Modus war), ist eine Kombination von der normalen Trace- 
Exception mit einer niedrig priorisierten Exception aufgetreten [z.B. bei Motorola Div/0-, 
Trap- oder Chk-Exception (im 68000er Handbuch nicht dokumentiert!)]. D.h. der Prozessor 

55 holte erst den Exception-Vektor des gerade aufgetretenen niedriger priorisierten Fehlers und 
lud das Statusregister und den Programmzahler auf den Supervisor-Stack und sprang dann 
noch wahrend dieser prozessorinternen Routine, noch vor Beginn der Exception-Routine in 
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die weitere Trace-Exception-Routine, wodurch wieder ProgrammzShler und das Status- 
Register auf den Supervisor-Stack geladen wurden. 

Mittels der auf dem Supervisor-Stack gesicherten Supervisor-Bits des Statusregisters ist nun 
feststetlbar, daB vor Trace bereits eine Exception auftrat und durch Vergleich des zweiten 
5 auf dem Supervisor-Stack gesicherten Programmzahlers mit den niedrigpriorisierten 
Exception-Vektoren ist nun die ursprGngliche Exception vor Trace ermittelbar. deren 
Exception-Nummer abgespeichert wird. 

d. ) Vergleich des IP^/PC^ auf dem Supervisor-Stack mit der Test-OpCode-Adresse: Wurde der 

\P^/PC U erniedrigt. blieb unverfindert Oder urn einen Wert groBer als der lahgstmogliche 
10 OpCode erhGht, war es ein Sprung. 

Wurde er um mehr als 4 Bytes erhdht, war es ein langer Befehl Oder ein kurzer VorwSrts- 
sprung - die Differenzierung ergibt dann daraus, ob Register verSndert wurden. 
Dieses Analyse-Ergebnis wird wieder abgespeichert. 

e. ) Vergleich des EFiagVStatus-Registers^ und aller Registerinhalte und der AdressRegister- 
15 Verweiainhalte, und der AdressRegister-Verweisinhalte einer max. AdressierbarkeitsiSnge 

darunter [wg. -(Adr.Reg.) ] mit den Original- Werten. 

In einer BitMaske wird nun geflaggt, welche Register geandert wurden und es wird analy- 
siert, welche Operationen mit welchen Quell- und Zielregistem stattgefunden haben kdnnten 
(hierbei Anderungen das EFIagVSfy beachten) und das Ergebnis wird in der ORT und OLT 
20 gespeichert (siehe Figs.5,19;6,20) und die OBT aktualisiert (Fig. 7,21 ). 

f. ) Bei Sprungen Analyse des EFIagSfc/SF^, ob der Sprung bedingungsabhangig war. 

1.3.5 Realisierung der GrundbedOrfnisse: 

25 

1.3.5. 1 Realisierung kunst/ichen Schmerzes: 

Schmerz wird durch die Verletzung des Systems verursacht. Der ursprunglichste Schmerz in der 
biologischen Evolution kommt bereits beim Einzeller vor und ist die Verletzung der DNA im 
Zellkern. Ist die DNA verletzt, muS sich der Einzeller unter Aufbringung seiner Ressourcen die 
30 Zeit nehmen, seine DNA zu reparieren. Er tut dies, indem er die fehlenden Aminos3uren in der 
defekten Doppelhelixhalfte durch komplimentfire Basen der intakten Doppelhelixhaifte kompli- 
mentar ersetzt. 

Das KB-Programm wird doppelt in's RAM geladen. Fiihrt das KB-Prg. (oder ein anderes) einen 
Befehl aus, der seinen aktiven oder inaktiven Code im Speicher uberschreibt, wird es also in der 

35 aktiven oder inaktiven Form verletzt, kann es diese Verletzung anhand einer Anderung seiner 
Checksum erkennen und muB sich nun die Zeit nehmen, bei Verletzung des aktiven Codes nun 
in den bisher inaktiven Squivalenten Code zu springen und dann beide Codes 32-Bit weise 
Overgleichen und an der Stelle der Ungleichheit das DoubleWord seines Codes mrt 
unverfinderter CheckSum an die verletzte Stelle des Codes mit veranderter CheckSum 

40 schreiben, um sich zu heilen. 

1.3.5.2 Realisierung kunstfichen Hungers: 

Hunger ist drohender Energieverlust. Energie wird in den Zellen u.a. durch Umwandlung von 
Adenosintriphosphat in Adenosindiphosphat erzeugt. Die Energie zum Aufbau von Adenosintri- 
45 phosphat aus Adenosindiphosphat wird durch Verbrennung von Glucose gewonnen. Fehlende 
Energie macht in den Zellen den Stoffwechsel und somit jede Handlung, Reaktion auf Schmerz 
oder die Seibstheilung bei Verletzung unmogltch. 

Die "Energiemenge" des KB-Programms lafct sich durch die H6he eines Werts in einem 
Datenregister modellieren. Es ware nun moglich, Hunger durch abnehmende Stromversorgung 
50 des Prozessors durch externes auslesen dieses Datenregisters und Erhdhung eines Ohmschen 
Widerstandswerts der Prozessorstromversorgung zu realisieren. Eine weniger authentische, 
hardwareungebundene Losung ist auch mdgfich: 

Fehlende Energie ist dem Lernprozess abtrfiglich. Bei mafcigen Werten in o.g. Datenregister 
treten Fehler beim Lernen aus den OpCode-AusfQhrungen auf. Bei geringen Werten ist das 
55 Lernen aus OpCode-AusfOhrungen nicht mehr mdglich und kleinste Werte in diesen Daten- 
register lassen gespeichertes Wissen vergessen. Ist der Wert auf null tritt zusatzltch Schmerz, 
also EigenCode-Vertetzung auf. 
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Das KB-Programm muft also bei Hunger OpCodes finden und ausfuhren, die den Wert dieses 
Daten registers erhdhen. 

Die abnehmende Energie, also das entstehen von Hunger, wird dadurch simuliert, daft das KB- 
Programm selbst nach jeder Handlung ( = OpCode-AusfQhrung) dieses Register urn 1 erniedrigt. 

5 

1.3,6 Planen nach den Kriterian des Be wertungssy stems: 

Hat das Indivtduum aile ihm moglichen OpCodes getestet und sich die Auswirkungen der 
10 verwendbaren Befehle gemerkt, kann es aufgrund seines Wissens zur Befriedigung seiner 
Grundbediirfnisse und zur Erreichung von Programmierzielen nun lernen zu planen: 
Hierfur reiht es OpCodes zu Kombinationen aneinander, fuhrt diese unter alien Anfangsbeding- 
ungen aus und wertet wieder aus, was diese Code-Kombination bewirkt hat. 
Da meist Idngere Kombinationen zur Ziellosung notwendig sind. plant es die Codezusammen- 
15 stetlung, in dem es zielgerichtet nur die Codes zur Kombination benutzt, die keinen Schaden 
anrichteten, also nicht den eigenen Code uberschrieben und am besten uberhaupt keine RAM- 
Schreibzugriffe machten, ferner keine verbotenen Register bzw. Operationen benutzten 
iAQT unused Jtegi$ters_BitCode\ADTMnusedJ)perations_BitCode) und auch keine Exceptions 
verursachten, wo man bei Divide-Error und Overflow-Exception toleranter sein sollte. OpCodes 
20 die gewOnschte Ziel- und Ouellregister benutzen, werden wiederum bevorzugt kombiniert 
(AD >T . a II source/dest Registers _BitCode\ . 

AD1 .aim Jul fill _valuation mode bestimmt, ob die Bewertungsfunktion in SQL oder direkt in 
Maschinensprache vorliegt. Fur den normalen Anwender ware die langsamere SQL-Variante 
benutzerfreundlicher und der Spezialist wird fiir komplexere Aufgaben sicher schnelle 
25 Zielerfullungs-Bewertungsfunktionen in Maschinensprache bevorzugen. 



1.3.7 Das dynamlsch-reflexive Bewertungssystem: 

30 1.3.7.1 Programmierzieln^he-Bewertung: 

Die ADT.aim fulifilled_Flag_Function( AimJD ), gibt TRUE zuriick, wenn das Programmierziel 
erreicht wurde und die VFT. Valuation Junctioni Type = , A', AD1. aim Jull filled _Fiag Function, 
VFT. Function JDJthain ), liefert einen" signed-byte Wert, der besagt, wie nah die aktuelle 
CLT(n)-OpCode-Kombination bei den gegebenen Anfangsbedingungen der Ziellosung kommt. 

35 Das Ergebnis wird in CLT(n). aim yaluation gespeichert und bildet im Vergleich mit der letzten 
CLT(n-1 ). aim ^valuation den Gradient CLT(n). gradient aim ^valuation. 

Da das Lflsungsprogramm jedoch fOr alle Anfangsbedingungen funktionieren muB, werden die 
maximale und die durchschnittliche Wert vol ligkeit der OpCode-Kombination als Mittelwert aller 
Anfangsbedingunen in CBT(n). max_aim_yaluation bzw. CBT (x\).avg_aimjrafuation abgelegt; die 
40 Gradienten zu den Wert en der letzten CBT(n-1) bilden CBT(n). max _grad_aim_yaluation und 
CBT[n).avg _grad aim valuation* 

Bei jeder Bewertung wird VFT .boundary value jcounter hochgezahlt, wenn ein Grenzwert von 
-128 bzw. +127 vergeben wurde und equivalent fowvatue jcounter, wenn eine Bewertung 
zwischen -1 6 und + 1 5 auftrat. 

45 Anhand dieser statistischen Daten und einer exakten Auswertung aller CLT {\).aim_vaiuation, 
z.B. indem man ein kleines Wertebereichs-Fenster durchlaufen la&t und die Eintrage je 
Fensterbreite und -offset zShlt, bewertet die S AC. Aim Self _Valuation_Func nach jeder 
Programmierziel-Erreichung der Bewertungs-Ergebnisse der VFT .Valuation Function und somit 
deren Effizienz. Fallen z.B. die meisten Bewertungsergebnisse auf die Grenzwerte, war die 

50 Bewertungsfunktion zu steil und sie mud abgeflacht werden, also in der VFT .Function ID Chain 
mehr Elemente mit negativem FIT. Function Flatten enthalten. Umgekehrtes girt, wenn die 
meisten Bewertungsergebnisse einen hohen V?lJow_yalue_counter -Wert verursachten. 
Nach jeder Programmierzielerreichung Ifiuft somit eine Selbstbewertung der Bewertungsfunktion 
ab und ein weiterer Programmierschritt der selbstprogrammierung der Bewertungsfunktion: 

55 Zur Bewertungsfunktion kommen neue Elemente hinzu und manchmal muft auch eines wegge- 
lassen werden und der Steilheitsgrad wird angepaSt. Dann wird die Bewertung erneut 
vorgenommen und uberpriift, ob die verSnderte Bewertungsfunktion einen besseren 
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Wertebereich geliefert hatte. War der neue Wertebereich nach der Selbstbewertung durch 
SAC .Aim_Se!f_Valuation_Function schlechter wird die Anderung der Bewertungsfunktion 
verworfen und eine andere Anderung versucht. Verbesserte die.Bewertungsfunktionsanderung 
den Wertebereich, wird die nachste Verbesserung versucht und wenn die Selbstbewertung 
5 einen guten Wert ergibt, mit der nSchsten Programmieraufgabe fortgefahren. 

1.3.7.2 Dynamische En&rgiebewertungsfunktion: 

Das energiespezifische Bewertungssystem ist folgenderma&en dynamisiert: 
0.)Da die Ergebnis-Werte des Bewertungssystems hier auf den Wertebereich von signed J>yte 
10 beschrankt sind, wird die Bewertungsfunktion in eine Rahmenfunktion eingebettet: 

Bewertungsergebnis := MINI MAX( Bewertungsfunktion, -128), +127) ] 
1 .)Die Bewertungsfunktion 0-ter Ordnung ist "wie satt bin ich nach der Handlung ?": 

Bewertungsfunktion(O) ; = MIN[ MAX( Energy jifter, -1 28), +1 27) ] 

2. ) Die Bewertungsfunktion 1-ter Ordnung ist "wieviel satter bin ich nach der Handlung ?": 
15 Bewertungsfunktiond } : = MIN[ MAX( Energy _after - Energy _be fore, -1 28), + 1 27 ] 

3. ) Da das Energieregister vom Typ unsigned integer (DWord) ist, waren die Rahmen bei der 

Bewertung zu schnell erreicht, deshalb entweder geringer Logarithmus oder: 
Bewertungsfunktion! 2) := MIN[ MAX[ SQRT( Energy after - Energy Jbefore I, -1281, +127] 

4. ) Jetzt ergflben sich falsche Werte bei negativen Energie-Gradienten, deshalb 3.Wurzel oder: 
20 Bewertungsfunktion(3) : = MINI MAX[ SGN( EnergyGrad )*SQRT( EnergyGrad I -1 28], ♦ 1 27], mit 

EnergyGrad - Energy jafter - Energy Jtefore 
MSglicherweise ware auch die Funktion %*SQN{ EnergyGrad )*S0RT( SQRT{ EnergyGrad ) ) besser, 
da diese exakt bis zu den Rahmenwerten reicht. Aber vielleicht warden auch die Rahmenwerte 
fast nie erreicht und eine feinere Gliederung um den Nullwert ware vie) wichtiger. 

25 Dies hSngt davon ab, wie oft die Rahmenwerte erreicht werden und wie viele Energie- 
Gradienten kleine Werte aufweisen. Vielleicht muS auch der Ergebniswert starker gewichtet 
werden und eine Gradientbewertung reicht ailein nicht aus; ferner mufi mitberOcksichtigt 
werden, wievielefwelche weitere(n) Register neben der Energi eve r§nde rung mitbetroffen sind 
und weiche OperationsTypen ausgefuht wurden, u.s.w., und schlieBlich die Ausfuhrungszeit 

30 der Bewertungsfunktion selbst. Deshalb muB sich das energiespezifische Bewertungssystem im 
Laufe der Zeit verfeinern und anpassen (wie bei intelligenten biologischen LebensformenK 
In dynamic embedded [PL/]SQL ist das verSndern und neu parsen der als String gespeicherten 
Bewertungsfunktion kein Problem. Wegen der Ausfuhrungsgeschwindigkeit und der Implemen- 
tationsfahigkeit voriger Aufgabenl6sungen soil jedoch die Bewertungsfunktion zukunftig in 

35 Maschinensprache erfolgen. 

Die Programmieraufgabe der Verbesserung der energiespezifischen Bewertungsfunktion wird 
ebenfalls nach jeder Programmierzielerreichung angegangen. 

Bewertungssystem und Bewertungsergebnisse sind immer reflexiv. 

40 

1.3.8 Selbstb&wu&twerdung, Reproduktion und Evolution: 

Durch den Selbstreperaturvorgang bei Schmerz kennt das Programm seine Lage im Speicher. Es 
45 kann nun die Auswirkungen seiner eigenen OpCodes der Reihe nach testen. Erkennt es spater 
einmal die Gesamtauswirkung seiner ganzen CodelSnge, wird es sich seiner selbst bewufct, 
kann seinen Code replizieren und aufgrund seines Wissens hierbei bewuSt verandern (z.B. das 
tastige Erniedrlgen des "Energie '-Registers entfernen). Die intelligente Reproduktion ist der der 
genetischen Reproduktion weit tiberlegen, da bei letzterer nur auf vorhandene DNA zuruckge- 
50 griffen werden kann und hier der eigene Programmcode bewuBt beliebig verandert und erweitert 
wird. 
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1 .4. Programmieraufgabenstellurtg und Beispiele der Zielerreichung 

Dem KB-Programm wird nun eine beliebige Programmieraufgabe gestellt, und es erhait in 
ADT.aim fulfilled J=lag_Function einen Priifungsalgorithmus, mit dem es Oberprufen kann, ob es 
5 die Aufgabe erfullt hat. 

Seine Aufgebe ist nun, ein Programm zu schreiben, dad die gestellte Aufgabe lost. 



1.4. 1 Beispielaufgabe 1: Ersteliung ernes Programms zur Berechnung des Mittelwerts: 

10 

Eine sehr einfache, aber leicht nachvollziehbare Aufgabe f(ir das KB-Programm k6nnte sein: 
"Schreibe ein Programm, das den Mittelwert 2er beiiebiger Integer-Zahlen berechnet." 
Das KB-Programm hat diese Aufgabe erfGllt, wenn die Differenz von der Ergebnis-Zahl zur 
kleineren Zahl gleich der Differenz von der Ergebnis-Zahl zur grflfteren Zahl ist, und dies fur 
15 beliebig viele Eingabe-Zahlenpaare zutrifft. 

Das KB-Programm kennt jedoch den Befehlssatz des Prozessors nicht - ihm stehen lediglich die 
OpCodes zur Verfugung, die keinen Schaden verursachten und es kennt einen Teil deren 
Wirkungen bei einigen unterschiedlichen Anfangsbedingungen. 

Durch das Corruption-Healing Oder das Energie- Register kennt es bereits einfachste Aufgaben 
20 wie "fOhre keine Handlurtg aus, die Schmerz verursacht" oder "fiihre Handlungen aus, die mich 
satt machen". 

Zur Erreichung von wirtschaftlichen Zielan benfltigt es nun Bewertungsvariablen, die ihm Dinge 
sagen wie 

a. JWieviel naher oder weiter weg vom Ziel hat mich diese Befehlskombination gebracht (das 
25 jeder einzelne Befehl davon gegenteilige Wirkung haben kann, ist hier nicht von Interesse). 

b. ) Wieviele Taktzyklen habe ich fur die Ldsung verbraucht. 

c. ) Wieviele Bytes ist main Programm lang (wieviele OpCodes mit wetchen Langen). 
Diese Tabellen-Spalten sind: aim valuation; cycles _pf execution; OpCodeJengthorJump. 

30 Die Eingabe-Werte der Beispiel-Aufgabe seien in den ersten beiden Datenregistern (EAX n , EBX^ 
bzw. DO^DI^ bzw. GPRO v , GPRI^), i.F. ROund R1. 

Der Ausgabe-Wert soil im dritten Datenregister (ECX 7l |D2 /7 |GPR2 t|; ) i.F. R2 erfoigen. Ist die Auf- 
gabe fur beliebige Eingabewerte gelbst, ist das Programm fertig, da es sich wegen der Ein- und 
Ausgabevariablen um eine Funktion handelt. Bei mehreren Lbsungen wird die mit den wenigsten 
35 verbrauchten Taktzykien gewahlt. 

Die aufgabenspezifische Zielerreichungs-Bewertungs-Funktion, die zur Berechnung von 
OLT .aim valuation bendtigt wird, ist somit in diesem Beispiel: 

ADT. aim fulfilled _Flag_Function{ Mittelwert mit o.g. Registern ) = [(R2-R0) = (R1-R2)] 

Hier kann jedoch das Problem auftreten, daS ein Eingabe-Wert gerade und der andere ungerade 

40 ist und die Aufgabe deshalb mit dieser Eingabe-Kombination somit manchmal keine Ldsung hat. 
Das KB-Programm wird mehrere Lflsungs- Programme finden und sich fur dasjenige entscheiden, 
das am wenigsten Taktzyklen verbraucht, also das Ergebnis am schnellsten liefert. 
Moglich ware bei CBT(3) folgendes Ldsungsprogramm: MOV R0,R2 ; ADD R1,R2 ; SHR R2 
(natllrtich im Maschinencode des verwendeten Prozessors - beim Pentium ware das die 48-Bit- 

45 Zahl $89C2.01CA.D1EA, bei Motorola $2400.D282.E2C2 und beim PowerPC eine 96-Bit Zahl) 



1.4.2 Beispielaufgabe 2: Ersteliung elnes Programms zur Berechnung der Kubikwurzel: 

50 Eine weitere einfache Aufgabe ware "Schreibe ein Programm, das die Kubikwurzel aus einer 
reellen FFP-Zahl (32-Bit) berechnet"; die Eingabe soli in RO (EAX*), die Ausgabe in R3 (EBX*) 
erfoigen. 

Das KB-Programm hat diese Aufgabe erfullt, wenn die Ergebnis-Zahl mit ihrem Quadrat multipli- 
ziert den Anfangswert ergibt: 
55 => aim Julfilled_Flag_Function( Kubikwurzel ) = [(R3*R3*R3) = RO] («- natDriich in FFP-MultiplJ 
Einen Einzelbefehl wie bei der Quadratwurzel (FSQRT) gibt es bei der Kubikwurzel nicht. 
Ein Ergebnis konnte bei CBT(8) beim Pentium II folgendermafcen aussehen: 
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Op1(16b): MOV CL,3 ;ECX = $7777:0003 [1011.0001:0000.0011] 

Op2(16b): FLD1 ;ST<0> = 1.0 [1101.1001:1110.1000] 

0p3(16b): FIDIV CX ;ST(OM'/ 3 [1101.1110:1111.0001] 

Op4(16b): FLD EAX ;ST(0) = R0 ;ST(1 )= % [1101.1001:1100.0000] 

5 Op5(16b): FYL2X ;ST(0)= V 3 !og 2 (R0) [1101.1001:1111.0001] 

Op6(16b): FLD1 ;ST(0)= 1 .0 ;ST(1) = '/> log 2 (R0) [1101.1001:1110.1000] 

Op7(16b): FSCALE ;ST<0>= 1 .0*2*[V 3 log 2 (R0)J [1101.1001:1111.1101] 

Op8(16b): FST EBX ;EBX = 2*[V 3 log 2 (RO)} [1101.1001:1101.1011] 

(natOriich nur die 2.Spalte als 128-Bit-Zahl.) 

10 Hexadezimal ware das B103.D9E8.DEF1 .D9C0:D9F1 .D9E8.D9FD.09DB. 

Dies ware eine mdgliche Losungszahl ( = Programm) fur die gestellte Aufgabe (es gibt bestimmt 
auch kurzere oder schnellere Ldsungen). 



15 1.5. Festplatten-Speicherbedarf und Vergessen 

in beiden Beispielen ware man zwar mit 1 6-Bit-Befehlen ausgekommen, jedoch wird ersichtlich, 
daB bei groBeren Programmieraufgaben der Festplattenspeicher knapp wird. Deshalb wird das 
KB-Programm unwichtige OpCode-Kombinationen vergessen mussen. 



20 



7.5. 1 Tabellengrd&en: 



1ST, RIT und CIT fallen kaum ins Gewicht. 

Theoretisch kdnnte s/>e(0BT) = 2 32 * £ Bvtes( Spalte(i) ) = 485 GB groB werden. jedoch sind 
25 auch bei einem RlSC-Prozessor nie alle 32-Bit-Kombinattonen als Befehl genutzt und realistisch 
sind im Mittel bei RISC-Prozessoren c.a. 28 Bit => 30 GB und bei CISC-Prozessoren 20 Bit => 
118 MB (die meisten sind dort 16 Bit-Befehle; es gibt wenige 8-Bit- und einige 24- und 32-Bit- 
Befehle, und langere als 3 2 -Bit-Befehle werden hier nicht berQcksichtigt). 

Bei den 62 Anfangsbedingungen kann sizeiOLT) = 2l 20 " 28 J * 62 ♦ Z Bytes( Spalte(i) ) = 3 
30 (CISC! .. 832 (RISC) GB groB werden und s/z»<ORT) c.a. genauso groB, wenn man bedenkt, 
daB durch ein OpCode meist ein Zielregister und ein Quellregister betroffen ist, moglicherweise 
auch keines oder nur ein Zielregister und selten mehrere Register. Da es jedoch mehrere 
mogliche zugehorige Operation JBitCodes geben kdnnte. wurde sich die TabeilengrbBe erhohen, 
wenn dies nicht durch die vielen Opcodes, die eine Exception auslosen, kompensiert wurde. 
35 Ein weitaus groBeres Problem kdnnte das exponentielle Wachstum der CxT(i) darstellen, da fur 
jedes i ein Faktor von 2 120 - 281 hinzukommt. Dies wird jedoch durch das Bewertungssystem 
kompensiert, das mit abnehmendem Restspeicher seine Toleranz einschranken kann - so 
konnen Kombinationen von vornherein ausgeschlossen werden, die Codes bzw. Kombinationen 
mit geringer CBT(i). max aim valuation (bzw. avg aim valuation) kombinierten wiirden. 
40 Auch wenn der Speicherbedarf jetzt noch hoch erscheinen mag, durfte dies in naher Zukunft 
kein Problem mehr darstellen. Auch die mit den TabellengrGBen und Kombinationsmdglichkeiten 
wachsenden Rechenzeiten werden durch immer grdBer und schneller werdende Festplatten und 
immer leistungsfahigere Rechner bewSltigbar. 



45 

1.5.2 Vergessen: 

Wie bei alien intelligenten Lebensformen muB das System unwichtige und weniger wichtige 
Informationen vergessen kdnnen, weil 
50 a.) der Speicherplatz begrenzt ist und 

b.) die Zugriffszeiten werden unndtig langsam. 

Deshalb werden nach jeder zufriedenstellenden Zielerreichung, bei Eingabe eines neuen Ziels, 
die ELT und alle CxT(i)-Tabellen ab einem restspeicherabhflngigen Grad geldscht und die 
Codekombinationen bzgl. der neuen Programmieraufgabe in den verbleibenden CxT(i) neu 
55 bewertet und ab der geldschten CxT inkrementell dynamisch wieder neu angelegt. 
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1.6. BewuEtwerdung 

Durch try_and_error lernt das Programm was jede einzelne Handlung bewirkt und was 
Handlungsfolgen bewirken. 
5 Im Rahman des Corruption- Healings (bei versehentlichem Eigencode-Uberschreiben) muB es 
seinen Code reparieren und kennt so seine Position im Speicher. Wenn es einrnal die Wirkung 
der Handlungsfolge seines eigenen Codes erkennt, wird es seiner selbst bewufit und kann 
seinen Code reproduzieren und bei der Reproduktion bewuSt verbessem. 

Durch die so initiierte Evolution entsteht eine immer komplexere Form des kunstlichen 
10 BewuRtseins, das immer grtt&ere Aufgaben bewaltigen kann. 

1.7. Darstellung der wirtschaftiichen Vorteile 

15 Es handelt sich hier urn ein vollkommen neues Feld der Computer-Verwendung. Wahrend im 
Computer normalerweise von Menschen programmierte Programme ablaufen, die anwender- 
gesteuerte Anweisungen ausfuhren, programmlert das KB-Programm selbst programmierziel- 
orientiert Handlungen, die zukunftig ausgefOhrt werden sollen. 

20 Der Bedarf an Softwareentwicklung ist weltweit viel gr6Ser als das menschliche Potential an 
Software-Entwicklern. 

Ein Programm, das lernt, Programme selbst zu schreiben {und das gleich in Maschinencode), 
kann kleine Progremmier-Aufgaben selbst Idsen und wird im Laufe seiner " Evolution \ wenn 
man ihm ausreichend Speicherplatz ISSt. auch selbstandig lernen. komplexe Programme zur 
25 LOsung groSer Programmieraufgaben zu generieren. 
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2. Patentanspruche: 

0. Ein Verfahren, das in einem Computer-System mit Prozessoreinheit, RAM-Speicher und Fest- 
platten-Speicher selbsttatig normale Zahlen von Byte- bis Langwort-La*nge (4-Bytes bis hex. 

5 $FFFF.FFFF) oder noch (finger durch einfaches hochzahlen oder nach dem Zufailsprinzip 
generiert und diese dann an eine Speicherstelle schreibt 
dadurcb gekennzeichnet daB, 

es alle Exception-Vektoren in eigene Exception-Analyse-Routinen abfSngt und diese 
Exception-Vektoren und alle Registerinhalte und die Inhalte der Verweis-Register id. geringer 

10 Offsets (z.B. von Adressregi stern) und die eigene CheckSum z w isc he nspei chert und den 
Prozessor in den Supervisor-Modus schaltet und das Single-Steppen (Trace/Trap) einschaltet 
und den Programmzahler* Instruction-Pointer beim RQcksprung aus dem Supervisor-Modus 
auf den Beginn dieser Zahl setzt und dadurch diese Daten-Zahl als Maschinencode ausfuhrt 
(als ob sie programmierter Maschinencode ware) und nach dieser Ausfuhrung dieser Zahf die 

15 Wirkung dieser AusfOhrung in- oder nach der Exception- bzw. Trace/Trap- Analyse-Routine 
durch Vergleich der Exception-Vektoren und der CheckSum und der Register und der Inhalte 
der Verweisregister (id. geringer Offsets) mit den zwischengespeicherten Ursprungswerten 
analysiert. 

1 . Ein Verfahren nach Anspruch 0. dadurch gekennzeichnet, daS die Prozessor-Register und die 
20 Inhalte der Verweisregister id. geringer Offsets vorher auf unterschiedliche vordefinierte 

Anfangsbedingungen geladen werden und das beschriebene Verfahren pro generierter Zahl 
mehrfach unter unterschiedlichen Anfangsbedingungen ausgefOhrt wird [Fig. 24a, 24b], um 
bei der o.g. Analyse [Fig. 19, 20, 21] exaktere Informationen uber die Eigenschaften dieser 
Zahl als Maschinencode zu gewinnen und abzuspeichem. 
25 2. Ein Verfahren nach Anspruch 1, dadurch gekennzeichnet, daS das System mehrere solcher 
Zahlenkombinabtionen als Maschinencodebefehle aneinanderreiht und so die Auswirkung der 
Codekombination analysiert. [Fig. 24c] 

3. Ein Verfahren nach Anspruch 2, dadurch gekennzeichnet, daB das System mehrere solcher 
Maschinencodekombinationeh aneinanderreiht, und die Auswirkungen der miteinander kom- 

30 binierten Codekombinationen analysiert. 

4. Ein Verfahren nach Anspruch 1 bis 3, dadurch gekennzeichnet, daB dem System eine 
Prog ram mieraufgabe gestellt wird, und es bewertet, wie nah die analysierte Zahlencode- 
kombination der Losung der gestellten Programmieraufgabe kommt. 

5. Ein Verfahren nach Anspruch 1 bis 4, dadurch gekennzeichnet, daS das System an diese 
35 Zahlehcodes oder Codekombinationen gezielt diejenigen analysierten Zahlencodes oder Code- 
kombinationen anfugt, die aufgrund der analysierten Operation sart, den analysierten Quell- 
und Zielregistern und der ermittelten Bewertung aus Anspruch 4, anftigt, die aufgrund diesen 
Werten eine hohe Wahrscheinlichkeit haben, dafi die Gesamtkombination die gestellte 
Aufgabe an ehesten lost. 

40 6. Ein Verfahren nach Anspruch 5 das wiederum die Wirkung der Gesamtkombination analysiert 
und bzgl. der Zielerreichungsn3he bewertet. 
7. Ein Verfahren nach Anspruch 1, in dem Grundbedurfnisse Squivalent "kein Schmerz" 
( = keine Beschadigung des Systems) und "kein Hunger" ( = kein drohender Energieverlust) 
folgenderma&en modelliert sind: 
45 a. Schmerz, modelliert durch das uberschreiben, und dadurch wiederum notwendigwerdende 
reparieren, des eigenen Programmcodes, was Zeit kostet und das unter b. modellierte 
"Energie" -Register schneller dekrementiert 
b. Hunger, modelliert durch die stetige zeitabhangige Abnahme eines Registerwerts und 
negativen Systemauswirkungen bei niedrigen Werten, wie 
50 - den Verlust der FShigkeit der Bewertung von Zahlencodekombinationen bzgl. der Zieler- 

reichung bei niedrigen Werten, 

- Fehler bei der Bewertung der betroffenen Quelt- und Zielregister, sowie der Operations- 
art bei sehr niedrigen Werten, 

- den Verlust der Fahigkeit der Selbstreperatur (bei "Schmerz" - siehe a.) bei extrem nie- 
55 drigen Werten, 

- Abnahme der Spannungsversorgung des RAM durch hardwaremaSig an dieses Register 
gekoppelten variablen Widerstand, der sich bei zwei mal in Folge auftretenden extrem 
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niedrigen Werten im "Energfe" -Register erhdht. 
- Abnahme der Spannungsversorgung des Prozessors durch hardwaremaliig an dieses 
Register gekoppeiten variablen Widerstand, der sich bei drei mal in Folge auftretenden 
extrem niedrigen Werten im "Energie" -Register erhdht. 
5 8. Ein Verfahren nach den Anspruchen 1 bis 7, mit dem Unterschied, daft dem System keine 
Programmieraufgabe gestellt wurde, und die Zielerreichungs-Bewertung nun bei Maschinen- 
codes und Codekombinationen positiv ausfBllt, die keinen "Schmerz" verursachen und das 
"Energie'-Register erhOhen, und Kombinationen um so negativer bewertet, je mehr eigen- 
genutzten Speicher sie uberschreiben und je mehr sie das "Energie" -Register erniedrigen. 
10 9. Ein Verfahren nach Anspruch 8, das nicht nur wie oben Code generiert, sondern auch 
bestehenden vorgegebenen Code analysiert, wie z.B. seinen eigenen, um zu bewerten, was 
seine Codeabschnitte und auch sein Gesamtcode bewirkt. 

10. Ein Verfahren nach o.g. Anspruchen, bei dem die Bewertungsfunktionen bzgl. der System- 
ziele (Programmierziel, Energiespezifische Handlung, u.s.w.) dynamisch reflexiv sind, also 

15 neben der Verfolgung der Erreichung der Programmierziele und positiver energiespezifischer 
Handlungen (und ggf. weiterer Aspekte) Selbstbewertungsroutinen durchgefuhrt werden, die 
die Bewertungsfunktionen anhand ihrer Bewertungsergebnisse bewerten und die Bewer- 
tungsfunktionen verfindern, testen und wieder bewerten und dann eine verbesserte 
Bewertungsfunktion auswShien, um bei der nachsten Programmieraufgabe effizienter zu 

20 sein. 

11. Ein Verfahren nach Anspruch 10, bei dem das Bewertungssystem selbst Programmier- 
aufgaben steilen kann, deren Ergebnisroutine als Teilfunktionen der Bewertungsfunktion 
dienen kann, um die Bewertungsfunktion selbst zu verbessem. 

12. Ein Verfahren nach Anspruchen 1 bis 11, bei dem zusatzlich uber eine Tabelle der 
25 Betriebssystemroutinen die Funktionen, Ein- und AusgabeRegister und Einsprungsadressen 

der System-Routinen zur Verfugung stehen und so als CALLS vom KB-Programm in den 
Losungscode implement ert werden kdnnen. 

13. Ein Verfahren nach o.g. Anspruchen, in dem mehrere solcher Programme parallel laufen und 
das Eriernte aus den Opcode- und Kombinations-Ausfuhrungen austauschen kdnnen. 

30 14.Ein System nach Anspruch 13, in dem mehrere Rechner, auf denen je eins oder mehrere 

solcher Programme laufen, miteinander vernetzt sind. 
15. Ein Verfahren nach Anspruch 8, 11, 12 f 13 oder 14 in dem wieder ein Programmierziel 

vorgegeben 1st, deren Erreichung jedoch nlcht wie in Anspruch 5 oder 6 durch eine 

Zielannfiherungsbewertung bewerkstelligt wird, sondern in dem bei Codekombinationen, die 
35 sich vom Programmierziel entfernen, eine Erniedrigung des Energieregisters verursachen und 

Codekombinationen, die in Richtung der Erreichung des vorgegebenen Programmierziels 

gehen eine ErhShung des Energieregisters mit sich bringen. 



3.1.1 



3. Zeichnungen: 
3.1 Relational Da ten bank des KB-Wissens: 
ER-Diagramm der KB-Datenbank: 
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OIT 



1 :n-Referenz zu alien CxT(i) 
FIT, ELT, EBT, ADT, AST 



RIT 



1 : n 



EZJS 

1 ;n-Referenz zu alien CxT(i) 
FIT, ELT, EBT, ADT, AST 



ICT 



EJ 

1 :n-Ref . zu alien CLT(i),CRT(i) 



OBT 

7,21 


1 : n 


OLT 

6,20 


1 : n x m 


ORT 

5,19 






1 


1 : n x m 








1 




CBT(2) 

10 


1 : n 


CLT(2) 

9 


1 : n x m 
> 


CRT(2) 

3 


* 




1 


1 : n x m 






1 




CBT(3) 


1 : n 


CLT(3) 


1 : n x m 


CRT(3) 






1 


1 : n x m 








1 




CBT(4) 


1 : n 


CLT(4) 


1 : n x m 


CRT(4) 


*_ 





1 : n x m 



CBT{5) 
hierakt.CPT 



1:n 



1 : n 



CLT(5) 



1 ; n x m 



ADT 






12 



1:n 



Ref. zu alien CBT(i),CLT(i) 



AST 




n 


: 1 

• 


n 








1:n 




1:1 



VFT 






15 



1:n 



FIT 




13,14 




1:n 



SAC 



Fig.1 



CRT<5> 



Ref. zu alien CLT(i) 



1 : n 



1:1 





ELT 






17,22 


ii 


:n 


• 




EBT 






18,22 



1:n 



yl 

Fig. Verweis T 
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3. 1.2 Tabeilen der KB-Datenbank: 



Register-ldenthlkations-Tabeile: [RIT: jedem Prozessor-Reg. wird eine Reg.lD + Reg.BitCode zugeordnet) 



Register ID (PK) 


signed byte 


-128.. 127 


0 = Flags-Reg., = Daten-Reg., Adr.Reg., Adr.Reg.- 
Veiweise, FFP-Reg., Control-Reg., Debug-Reg., u.s.w. 
; neg.Reg.lD = Exc.Vect.Nr. <kein Reg.) 


Register BitCode 


number 


0..2 128 -1 


2 A Register ID, 0 bei neg. Register ID. 


Registertype 


chard) 


1 Byie 


Typ des Registers; # = Flags-Reg., D = Daten-Reg., 
A=Adress-Reg., V = Adr.-Reg. -Verweis, E = Excep- 
tion-Vector, u.s.w. (o.a\, je nach Prozessor). 


Register number 


byte 


0-127 


Nummer des {Regis ter~Type}-ReQ\sters. 


Register Description 


varchar2(32 


<32 Bytes 


optionale Beschreibung des Regi3ter[-Verweise]s. 



Register ID 


Register BitCode 




Register number 


Register Description 




0 


E 




(for alt Exception- Vectors} 


-8 


0 


E 


8 


Privilege-Violation Exception 




0 


E 




{for ail Exception-Vectors) 


0 


1 


# 


0 


Status-Register EFIagsJ 


1 


2 


D 


0 


Data-Register DO 




4 


D 




{for all Data-Registers D 1-D6) 


8 


8 


D 


7 


Data-Register D7 


9 


16 


A 


0 


Adress-Register AO 






A 




{for all Adress-Registers A 1-A6) 


16 


65536 


A 


7 


Adress-Register A7 ( = USP/) 


17 


131072 


V 


0 


Destination of Adress-Register AO 






V 




{for ail Adr.-Reg. -Destinations A 1-A6J 


24 


16777216 


V 


7 


Destination of Adr.-Reg. A7 [ = (USP)1 


25 


33554432 


V 


0 


Destination before Adr.Reg AO [- 
(AO)] 






V 




{for all Adr.Reg. -Dest before A1-A6) 


32 


$1.0000.0000 


V 


7 


Destination before Adr.Reg A7 [-(USP) 


33 


$2.0000.0000 


F 


0 


Floating-Point Data-Register FPR0 










{for all further Registers} 



Fig. 2b (RIT am Be/spiel Motorola) 



Spalte: 




Datentyp 


Wertebereich Bedeutung: 


IniConNr 


(PK) 


signed byte 


-31. .+30 


Anfangsbedingungs-Nr. 


Register ID 


(PK) 


signed byte 


0..127 


siehe RIT 


Register Value 


integer 


0..2 32 -1 


Wert des Registers bei dieser Anfangsbedingungs-Ni 



Fig. 3a 



Dafur werden 62»RegisterAnzahl Testwerte generiert, z.B, mittels folgender Funktion: 



Register_Value( IniConNr, RegisterJD ) = SGN( IniConNr) » INT( 2 A ABS(lniConNr/2> + Y 2 ) 

+ Primzahl( 3 » Register ID ) 



o.a. 



, mit Primzahl(0) = 0 und Primzahl(-n} = -PrimzahHn) ; keine 2 gleichen Register-[Verweis]-lnhalte. 



Fig. 3b 
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Operationsidentifikations-Tab.: [PIT: je Prozessor-Oper. wird erne Oper.iD+ Opar.BftCode ^ugeordnet/ 
Spafte: Datentyp Wertebereich Bedeutung: 



Operation ID (PK) 


signed byte 


-1..63 


Bit des Calculation BitCode - siehe Tabeilendaten. 


Operation BitCode (FK) 


number 


0..2' 28 -1 


2 'Calculation ID - siehe Tabeilendaten. 


Operation Type 


char( 5) 


5 Bytes 


5-Character-Code des Operations-Typs, siehe Fig. 4c 


Operation Mnemonic 


chart 5) 


5 Bytes 


AbkOrzung der Rechenoperation - siehe Tab. Da ten. 


OperationDescription 


varchar2<32 


<32 Bytes 


optionale Beschreibung der Rechenoperation (s.u.r. 



Operation ID 


Operation BitCode 


Operation Type 


Dp.Mnemonic 


Operation Description 


-1 


0 






? ?? 


unbekannte Operation 


0 


1 




111? 


TST 


Flags in Reg.[Verw.]-Abhangigk.setz. 


1 


2 




112! 


NEG 


Negation) Betragsbildung 


2 


4 




112! 


NOT 


bitweise Invertierung 


3 


8 




102 


MOVT 


feste Zahl~>Register[verweisl 


4 


16 




112 + 


ADD I 


feste Zahl addieren 


5 


32 




112- 


SUBI 


feste Zahl subtrahieren 


6 


64 




113* 


MUL1 


mit fester Zahl multiplizieren 


7 


128 




123/ 


DIVI 


durch feste Zahl dividieren 


8 


256 




113% 


MODI 


Divisionsrest einer festen Zahl 


9 


512 




112* 


SHLI 


FestZahl-mal verdoppeln 


10 


1.024 




112/ 


SHRI 


FestZahl-mal halbieren 


1 1 


2.048 




1121 


ORI 


Bits einer festen Zahl hinzuf ugen 


12 


4.096 




I12& 


ANDT 


Bits einer festen Zahl loschen 


13 


8.192 




112? 


BTST1 


Reg.IVerwJ-Vergteich m.festem Bit 


14 


16.384 




112? 


CMPI 


Reg.IVerwJ-Vergleich m. fester Zahl 


15 


32.768 


1122 


MOV 


Quelt-Reg.[v.J -> Ziel-Reg.lv.J 


1 0 


DO. boo 


1122+ 


TV Pi Pi 


neg.i verw.j-Muaiiiori 


j 7 


131 .072 


1122- 


SUB 


Reg.lVerwJ-Subtraktion 


18 


262.144 


1123* 


MUL 


Reg[Verw.]-MultipIikation 


19 


524.288 


1133/ 


DIV 


Reg.[VerwJ-Division 


20 


1.048.576 


1133% 


MOD 


Reg.[Verw.]-Divisionsrest 


21 


2.097.152 


1122* 


SHL 


Reg.[Verw.]-mal verdoppeln 


22 


4.194.304 


1122/ 


SHR 


Reg.[Verw.]-mal halbieren 


23 


8.388.608 


1122 I 


OR 


Reg.[Verw.]-Bits hinzufugen 


24 


16.777.216 


II22& 


AND 


Reg.[Verw.]-Bits loschen 


25 


33.554.432 


1121? 


BTST 


Reg.[Verw.]-Vergleich m. Reg.-Bit 


26 


67.108.864 


1121? 


CMP 


Reg.[Verw.]-Vergleich m. Reg.fVerw. 


27 


134.217.728 


:P00. 


JMP 


addiere feste Zahl -±PC t JE\P n 


28 


268.435.456 


CP1.< 


JLT 


Jump if CMP < 


29 


536.870.912 


CP1!> 


JLE 


Jump if CMP < 


30 


1.073.741.824 


CP1.= 


JEQ 


Jump if CMP = 


31 


2.147.483.648 


CP1!< 


JGE 


Jump if CMP > 


32 


4.294.967.296 


CP1! = 


JNE 


Jump if CMP * 


33 


$2.0000.0000 


CP1.> 


JGT 


Jump if CMP> 


34 


$4.0000.0000 


CP1!< 


JPL 


Jump if £ 0 


35 


$8.0000.0000 


CP1.< 


JMI 


Jump if < 0 


36 


$10.0000.0000 


CP1.* 


JCS 


Jump if Carry set 


37 


$20.0000.0000 


cpir 


JCC 


Jump if Carry clear 


38 


$40.0000.0000 


CP1.~ 


JVS 


Jump if Overflow set 


39 


$80.0000.0000 


CPU- 


JVC 


Jump if Overflow clear 


40 


$100.0000.0000 


CP2.< 


DJMP 


Decrement and Jump if Reg. < 0 


41 


$200.0000.0000 


PS1. . 


CALL 


PC^EIP^-UJSP^/ESPJ ; + JUMP 


42 


$400.0000.0000 


SP11. 


RET 


<USP u «Sfy+ -►PO/EIP* 


43 


$800.0000.0000 


.1. . . 


I??? 


unbek. Integer-Operation 


44 


*1 000.0000.0000 


. F . . . 


F??? 


^jnbek. Floating-Point-Operation 
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45 


k ^ a a r\ A A A A A K\ A A 

? 2000 . 0000 . 0000 


FF09 


FINIT 


mix rioatingroint-unit 


46 


>4000. 0000. 0000 


FI12 


r» t C T» 

C I ST 


Store Hoat.rO<ni-neg.— >inieger-nBg. 


47 


} 8000 . 0000 . 0000 


IF12 


FILD 


load Integer-Reg. — >FloatingPoint-Reg. 


48 


jl 4 AAA A — nIO 

$1 .0000*2^ 


IF22 + 


FIADD 


Floatingpoint add Integer 


49 


JL 0\ A A A A A A*50 

$2.0000*2*" 


IF22- 


FISUB 


Floatingpoint sub Integer 


50 


$4.0000* 2 32 


IF22* 


FIMUL 


Floatingpoint multipl. mit Integer 


51 


$8.0000* 2 32 


IF22/ 


FTDIV 


Floatingpoint teile durch Integer 


52 


$10.0000*2-" 


IF21 ? 


FICMP 


Float. Point-Compare Integer — >Flags 


53 


$20.0000*2^ 


: F02 


FLD# 


Konstante — ► FloatingPoint-Register 


54 


jl ji a a a a a — aQO 

$40.0000* 2 


. F12 1 


FABS 


F loatingPoint-Betragsbildung 


55 


AAA A. A. A A — . A *l *5 

$80.0000*2*" 


FF12 


FLD 


FloattngPoint-Kopieren 


56 


JL. « A A A AAA. - 0*30 

$ 100.0000*2*** 


FF22+ 


FADD 


FloatingPoint-Addition 


57 


$200.0000*2°^ 


FF22- 


FSUB 


rioaiingroini-ouuxraKiion 


58 


JL jj A A A A A A — 0*30 

$400.0000*2*" 


FF22* 


FMUL 


rioaiingrOini-iviuiiipiiKaiion 


59 


A o aaaa ^ nTO 

$800.0000* 2 


FF22/ 


r UI V 


rioaiingroim-uivision 


60 


A 4 A A A A A, A A — 0*^7 

$1 000.0000*2 JZ 


. F12@ 


t b^KI 


rioaimgroini-wurzei 


61 


jl A A A A AAAA^A^O 

$2000.0000*2*" 


. Fl 2@ 


FSIN 


FloatingPoint-Sinus 


AO 
Oil 




Ft 


FC0S 


Float inaPoint-Cosinus 


63 


$8000.0000*2 32 


.F12@ 


FATAN 


FloatingPoint-ArcusTangens 


64 


$1*2 48 


FF22* 


FEXP2 


y; = y*2 x , o.a\Exponentialfunktion 


65 


$2*2 48 


FF22/ 


FL0G2 


y:=x*k)q?v . o.a.Logarithmusfkt. 


66 


$4*2 48 


FF21? 


FCMP 


FloatingPoint-Compare ->Flags 


67 


$8*2 48 


$111 


SMOV 


Move from a special Register 


68 


$10*2 48 


I$ll 


MOVS 


Move to a special Register 













Fig. 4b 

mit dem Operation -Type Character-Code: 



1 . Zeichen = Quelle, 2. Zeichen = Ziel t mit: 



I 

F 
C 
P 

S 

$ 
I 



= unbekannt, Platzhalter fur alle moglichen folgenden 
= nichts 
= teste Zahl 

= Integer-Register-lVerweisJ-lnhalt 
= Floating-Point Register 

= CondrtionCode-Register (unterstes Byte v.EFIagVSFW 
= InstructionPointer/Programmzahler (EIPyPQ,) 
= StackPointer-Verweis 
= Vergleichsoperation ->Flags 
= ein Spezial-Reg., wie Flags-. Control-, Debug-, ... 
-Nicht fOr Vergleichsabfrage im 4.Fe>d 



S.Zeichen^Anzah! der betr.Quefl-Reg. id. des Zielregisters, wenn auch als Source verwendet 



4. Zeichen - Anzahl der betr.Ziel-Reg. 



mit Flags-Register ohne Instruction-Pointer. 



5. Zeichen = Rechen- Wirkung: 



= unbekannt 
= keine 

= Betragsbildung | Negation | bitweise Invertierung 

- Addition 

^Subtraktion 

= Vervielfaltigung 

= Teilung 

= Divisionsrest 

= Bitssetzen 

= Bits loschen 

= trigonometrische- oder Potentialfunktion 

= gro(Ser ? (Abfrage der Flags) 

= kleiner ? (Abfrage der Flags) 

= gleich ? (Abfrage der Flags) 

= Carry ? (Abfrage der Flags) 

= Overflow ? (Abfrage der Flags) 



Fig.4c 
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OpCode-Reqister-TabeUe: [ORT - von diesem OpCode* Anfangsbed. betroffene Register* Wirkung] 
Spalte: Datentyp Wertebereich Bedeutung: 



UpUOOB frf\/ 


integer 


n 932 1 
u. .z - 1 


i^ornpieie insiruciion, iruriccjitnj it ^ *+ oyico 


IniConNr (PK) 


signed byte 


-31.. 30 


Anfangsbedingungs-Nr. 


ReglsterJDdest (PK) 


signed byte 


0..127 


ein betroffenes Ziel-Register der Ausfuhrung, s. RIT. 


Register ID source (PK) 


signed byte 


1,0.. 127 


-1 oder ein mogliches Quell-Register, siehe RIT. 


value before change 


integer 


0..2 32 -1 


Wert von GeSndertem vor Anderung. 


value_after change 


integer 


0..2 32 -! 


Wert von Gedndertem nach Anderung. 


gradient if unsigned 


signed byte 


-128.. 127 


Erh6hungs-Gradient, wenn als unsigned definiert. 


gradient if signed 


signed byte 


-128.. 127 


Erhohungs-Gradient, wenn als signed definiert. 


valuesource 


integer 


0,.2 32 -1 


Wert von mfcglichem Quell-Register-lVerweis]- 
Inhalt 


Operations_8itCode 


number 


0..2 12 *-1 


Bltmaske, die aile zutreffenden Rechenarten dieser 
RegisterJDdest / Register J D_source -Kombination 
kennzelchnet (z.B.: 2 + 2 = 2*2 bei gleichen Reg's). 
Werte siehe CIT, Berechnung siehe Fig. 19. 



Fig.5 



Fur jede Register- oder Register- Verweisinhaits-Anderung derselben Ausfuhrung gibt es hier einen 
Eintrag, der die Register- [Verweis]- Werte vor und nach der Ausfuhrung, sowie dessen Anderungs- 
grad angibt, und einen Hinweis ein mGgliches Quellregister und auf die betreffende Operation, die 
stattgefunden haben kOnnte. (Packed. Tei I- Word/Byte und BCD werden nicht berucksichtigt.) 

Das letzte Adress-Reg. ist der StackPointer. Das letzte Daten-Regi9ter sei das "Energie" -Register. 
Als Adress-Register sei hier jedes Register bezeichnet, dessen Inhalt nicht nur ein Wert f sondern 
auch eine Adresse im Speicher sein kann, auf dessen Inhalt zugegriffen werden kann. 

Es kdnnen mehrere Register gleichzeitig verandert worden sein, deshalb diese zusatzliche 1:n- 
Tabelle, bei der Register JDdest die Identitat des geanderten Registers darstellt. Als mogliches 
Quellregister fQr die Anderung kdnnen u.U. mehrere in Frage kommen - diese Menge erhoht sich 
weiter durch die Summe aller moglichen Operationen. 

Deshalb identifizieren die folgenden Tabellen den QpCode und die betroffenen Register: 



OpCode-tem-Tabelle: fOL T - ermittefte Wirkung des OpCodes bei diesen AnfangsbedJ 



Spalte: 


Datentyp 


Wertebereich Bedeutung: 


OpCode (PK) 


integer 


0..2 32 -1 


Complete Instruction, truncated if > 4 Bytes 


IniConNr (PK) 


signed byte 


-31.. 30 


Anfangsbedingungs-Nr. 


active ChkSum corrupt 


boolean 


110 


Flag: aktives KB-Progr. Checksum changed 


inactive ChkSum corrupt 


boolean 


110 


Flag: inaktives KB-Proar. Checksum changed 


Exception Vect changed 


signed byte 


-128.. .0 


Register ID d. 1 . Qberschriebenen Exception-Vectors 


multiple Exc Vect_chg 


boolean 


1|0 


min.2 Exception-Vektoren wurden uberschrieben. 


Processor_Mode_Changed 


boolean 


1|0 


Flag: Prozessor-Modus wurde verandert (z.B. Trace) 


Number of Exception 


byte 


0..N + 1 


Exception-Nummer{ggf.je+ 1) I0: = keine Exc] 


OpCode_length_or Jump 


signed byte 


-128..127 


EIP^/PC w jetzt N Bytes weiter bzw. zuruck; -128 = 
$ FF = langer Sprung zurOck; 1 27 = $ 7F = langer vor. 


CCR before execution 


byte 


0..255 


Flags, die einen Sprung ausgelSst haben konnten. 


RegisterchangedBitCode 


number 


0.2 128 -1 


S2 A ORT.Register ID dest V ORT(OpCode,LfdNr) 


Register_source_BitCode 


number 


0..2 128 -1 


S 2* ORT. Register ID source V ORT(OpCode,LfdNr) 


max_Operatk>ns_BitCode 


number! 19) 


0..2^8-l 


■SORT .Calculation BitCode VORT(0pCode, IniConNr) 


min_Operations_BitCode 


number! 19) 


0..2 12 *-1 


^ORT.Calculation BitCode VORT(OpCode,lniConNr) 


time of execution 


integer 


0..2 32 -1 


DeciSeconds after (20.9.1994, 0:00:00,0 Uhr) 


cycles of execution 


byte 


1..266 


Taktzyklen der OpCode-Ausf uhrung 


aim valuation 


signed byte 


-128.. 127 


Ziel-Erreichungs-Bewertung bei diesen Anfangsbed. 


gradient aim valuation 


signed byte 


-128..127 


Unterschied zu CLTf n-h IniConNr ). aim valuation 



Rg.6 
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OpCoda-Basis-TabeJh: [QBT - ermitte/te Wirkung der OpCode-Ausfuhrung aus versch. AnfangsbedJ 
Spalte: Paten typ Wertebereich Bedeutung: 



Opcode (PK/ 


integer 


r\ o32 1 
U. . z° - 1 


Complete insirucnon, iruncaieu ir ? oyieb 


Execution counter 


byte 


0..255 


Anzani der vjl i -tintrage dis jeizi 


FatalErrorcounter 


byte 


0..255 


Anzahl der verursachten schweren Fehler: 
cnecKoum corrupt, cxcepiion_veci_cnanyeu, 

1 faCa OIL CllCaiCUi iIUvCjoUI iviuud uiiaii^cvi) 


low Error counter 




byte 




AnTahl Hpr D/>\s iHf* - Frm r nriftr Overflow -ExceDtlons 


Jump longOp probability 


signed byte 


' 1 *3Q 1 07 
- 1 zo.. 1 JL / 


vvanrscneinucnKcii. oeicin iol laii^N upwun | vjpi ui iy 


avg OpCpdeJump length 


signed byte 


1 OQ 1 07 
-1 £Om 1 Z / 


miiflapB HrirAWa/Crvi irvn-l finn A woo allan AllfiflihriJnflfM' 

mi IT IB iB upovwc/opi Ufiy uciiiyo vm i anon ^uoiuiiiuiiyd 


OpCode len unconfirmed 


boolean 


1 |0 


mm. eine Auweicnung von aer upv*uao-i-<jiiyB 


avg cycles of execution 


byte 


■1 'ICC 

1 ..25b 


mittierer zertverDraucn in i aKizyKien 


exec cycles unconfirmed 


boolean 


1 ..0 


mm. eine ADwejcnung von aer Anzani aer 1 aKizyiuen 


Register write probability 


signed byte 


-1 28.. 1 27 


wenrscneiniicnKeit. bereni scnreiui in negisier 


Register copy__probability 


signed byte 








ctnnoH |-%w4-q 

sfynou uyis 


-19ft 197 


Wahrscheinlichkeit* Befehl schreibt in Speicher 


Memory copy_probabflity 


signed byte 


-128.. 127 


Wahrscheinlichkeit: Befehl kopiert Speicher 


Reg to Mem probability 


signed byte 


-128.. 127 


Wahrscheintichkeit: Befehl kopiert Register d.Adr.Reg. 


Mem to Reg probability 


signed byte 


-128.. 127 


Wahrscheinlichkeit: Befehi kopiert d.Adr.Reg. in Reg 


Multi Reg write prob 


signed byte 


-128.. 127 


Wahrsch.: Befehl schreibt in mehrere Register. 


Multi Mem write prob 


signed byte 


-128.. 127 


Wahrsch.: Befehl schreibt durch mehrere Adr.Reg. 


Multi Reg to Mem prob 


signed byte 


-128.. 127 


Wahrsch.: Befehl kopiert min. 2 Reg. d.min.2 Adr.Reg. 


Multi Mem to Reg prob 


signed byte 


-128.. 127 


Wahrsch.: Bef. kopiert d.min. z Aar.neg. in min.^ neg. 


all_Reg_dest_BitCode 


number 


0..2 128 -1 


*s OLT. Register changed Bitcode V OLT(OpCode) 


cut_Reg_deat_BltCode 


number 


0..2 128 -1 


COLT. Register changed Bitcode V OLT(OpCode) 


all Reg source_BitCode 


number 


0..2 128 -1 


.sOLT.Register source Bitcode V OLT(OpCode) 


cut_Reg_source_BitCode 


number 


0..2 128 -1 


COLT.Register source Bitcode V OLT(OpCode) 


maxJDperationBitCode 


number 


0..2 128 -1 


.3 OLT.max Operation BitCode V OLT(OpCode) 


min Operation BitCode 


number 


0..2 128 -1 


COLT.min Operation BitCode V OLT(OpCode) 


all_Operatk>n_BitCode 


number 


0..2 128 -1 


.sOLT.min Operation BitCode V OLT(OpCode) 


c ut_0 perationBi tCode 


number 




^OLT.max operation bituoae v ul t iupv/oae; 


max write value 


integer 


0..2 J ^-1 


Maximun aller geschiebenen Werte 


mln write value 


integer 


0..2 32 -1 


Minimum aller geschiebenen Werte 


avg write value 


integer 


0..2 32 -1 


Mittelwert aller geschiebenen Werte 


max write gradient 


integer 


0..2 32 -1 


maxima le Differenz des gefinderten Werts 


min write gradient 


integer 


0..2 32 -1 


minimale Differenz des geanderten Werts 


avg write gradient 


integer 


0-.2 32 *1 


aurcnscnnittiicne Dirterenz aes geanaenen wens 


evaluated source Register 


signed byte 


-1 ,0..127 


Quellregister ID (nacn OBT-Auswertungj 


evaluated_source_NumReg 


signed byte 


-128, -1, 
0..1 27 


-128 4 LOB ist feste Quellzahl; 0..1 27 = weitere 
iiueiiregister iu, ^=-i inacn udi -Muswcnuiiy; 


evaluated dest Reo inter 


signed byte 


-1, 0..12: 


Zielregister nach OBT-Auswertung 


evaluated_dest_Register2 


signed byte 


-1, 0..12: 


m6gl. 2.Zielregister nach OBT-Auswertung oder Flags 
(bei min. 2 echten ZielReg. wird Flags nicht genannt). 


evaluated Operation ID 


signed byte 


-1,0..63 


wahrscheinlichste ausgefuhrte Operation (Ausw.) 


Confirmation counter 


byte 


0..255 


gleiche Auswirkung bei neuen Anfangsbedingungen 


max aim valuation 


signed byte 


-128.. 127 


max. Wertvolligkeit des OpCodes fQr Zielerreichung 


avg aim valuation 


signed byte 


-128.. 127 


mittlere Wertvolligkeit d.OpC. fur Zielerreichung 


maxgradaimvaluation 


signed byte 


-128.. 127 


max.Emahung der Zielerreichung gegenuber der kurze- 
ren OpCodeKombination ohne diesen 0pCode[CBT(i-1 )] 


avg grad aim valuation 


signed byte 


-128.. 127 


mittl. Erhohung der Zielerreichung durch letzten OpC. 



FjSj_ 

Datentypen: Boolean 1 Bit, BCD/Nibble 4 Bit, Byte/char(1) 8 Bit, Word/short 16 Bit, DWord/lnteger 
32 Bit, QWord/numberfW) 64 Bit, number/number(38,0) 128 Bit (38 Digits & 16 Bytes). varchar2{N) 
String variabler L3nge aus max.N Character, long sehr langer String aus max(longDef) Character. 
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Die folgenden Kombtnations-Tabellen werden dynamisch angelegt, haben die gleichen Non-PK- 
Columns, wis die OBT bzw. OLT bzw. ORT, jedoch fOr jede zusStzliche Code-Kombinations-Anzahl 
einen weiteren OpCode mehr im PK: 



Kombinations-Reghter-TabeUe: ICRTti), i=Anz.OpCodes, fur die OpCode-Kombination, CRT(1)=ORT) 



Spalte: Datentyp Wertebereich Bedeutung: 



OpCode 1 (PK) 


integer 


0-232-1 


Opcode 1 (erster der Befehlskombi nation) 


(for all OpCodes) (PK) 


je integer 


0-2 32 -1 


{fur atle Opcodes 2 bis N-1} 


OpCode N (PK) 


integer 


0-2 32 -1 


Opcode N (letzter der Befehlskombinationl 


IniConNr (PK) 


signed byte 


-31. .30 


Anfangsbedingungs-Nr. 


Register ID dest (PK) 


signed byte 


0..127 


ein betroffenes Ziel-Register der Ausfiihrung, s. RIT. 


Register ID source (PK) 


signed byte 


-1..127 


-1 oder ein mdgliches Quell-Register, siehe RIT. 


(Gfeiche Spa/ten, wie in 
der OpCode-Register- 
Tabelle.) 


s.o. 


s.o. 


jede Kombinations-Register-Tabelle hat unter dam 
PK die gleichen Spa/ten, die die OpCode-Register- 
Tabetle auch hat 



Fig.8 



Spalte: 


Datentyp 


Wertebereich Bedeutung: 


OpCode 1 (PK) 


integer 


0-2 32 -1 


Opcode 1 (erster der Befehlskombinationl 


{for all OpCodes} (PK) 


je integer 


0-2 32 -1 


{fur aile Opcodes 2 bis N-1} 


OpCode N (PK) 


integer 


0-2 32 -1 


Opcode N (letzter der Befehlskombinationl 


IniConNr (PK) 


signed byte 


-31.. 30 


Anfangsbedingungs-Nr. 


{sonst gleiche Spalten, 
wie in der OpCode-Lern- 
\Tabelle.) \ 


s.o. 


s.o. 


jede Kombinations-Lern-Tabelfe hat unter dem PK 
die gleichen Spalten, die die OpCode-Lern-Tabefie 
auch hat. 



Fig.9 



Kombinations Basis Tabelle: [CBTffl. i=Anz. OpCodes, fur die OpCode-Kombination, CBT(1)=OBT] 



OpCode 1 (PK) 


integer 


0-2 32 -1 


Opcode 1 (erster der Befehlskombination} 


(for aH OpCodes) (PK) 


je integer 


0-2 32 -l 


{fur alle Opcodes 2 bis N-1 } 


OpCode N (PK) 


integer 


0-2 32 -1 


Opcode N (letzter der Befehlskombination) 


{sonst gleiche Spalten 
wie in der OpCode-Basis- 
TabelleJ 


s.o. 


s.o. 


jede Kombinations-Basis-Tabelle hat unter dem PK 
die gleichen Spalten, die die OpCode-Basis-Tabelie 
auch hat. 



Fig. 10 



CBKmax.) = CPT = Kombinations-Plan-Tabelle = Entstehungsort des Ergebnis-Programms. 



Programmierziel- und Bewertungsfunktions-Tabetlen: 
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Zielldsungs-Tabefie: (AST - Losungen (aim-solution) alter gestellten Programmier-Aufgaben] 



Spalte: 


Datentyp 


Wertebereich Bedeutung: 


Aim ID (PK) 


short 


0..65535 


Identifier des Programmierziels 


Solution Nr (PK) 


byte 


0..255 


laufende Nr des Losungsprogramms 


aim Program 


long 


String 


OpCode-Kombination des L6sungs-Prg. als String. 


Program length 


short 


1. .65535 


Ldnge d. L6sungs-Prgs in Doublewords, aufgerundet 


cycles of execution 


integer 


1.. 232-1 


Ausf uhrungszeit des Los.-Prgs in Taktzyklen 


used Registers Bit Code 


number 


1..2 128 -1 


Bitcode aller im Los.-Prg. benutzten Register 


used Operations Bitcode 


number 


1..2 128 -1 


Bitcode aller im LOs.-Prg. benutzten Operationen 


used aim Valuation Func 


signed short 


0..32767 


Identifier der benutzten Zielnahe-Bewertungsfuntion 



Fig.11 



Ziel-Beschrelbungs-Tabette: [APT - Ziefprogramm-Beschreibung (aim-description) und identifikation] 



Spalte: Datentyp Wertebereich Bedeutung: 



Aim ID (PK) 


short 


0..65535 


Identifier des Programmierziels 


aim Description 


varchar2t32 


<32 Bytes 


Beschreibung der Programmieraufgabe 


used Processor Mode 


integer 


0-2 32 -1 


Flaas uber CCR i Control- Register-Bits 


all dest Register BitCode 


number 


1..2 128 -1 


Bitcode aller Ausgabe-Register der Aufgabe 


all source Register BitCode 


number 


1..2 128 -1 


Bitcode aller Eing a be -Register der Aufgabe 


unused Regiser BitCode 


number 


1..2 128 -1 


Bitcode aller nicht zu benutzenden Register 


unusedOperationBrtCode 


number 


0..2 128 -1 


Bitcode aller mit Sicherheit nicht zu verwendenden 
Operationen (default = $0000.0000:0000.0000) 


8imJmplement_solutions 


long 


String 


String aus AimJD's (words) fruherer, hier einzubin- 
dender Losungen. 


aim fulfill valuation mode 


boolean . 


on 


Ziel-Bewertungsfunktion: 0=SQL ; 1 = Maschinencode 


aim f utfilledFlagFunction 


varchar2(99 


£99 Bytes 


boorsche Ziel-Erreicht Erkennungs-Funktion als String 


aim Valuation Function ID 


signed short 


0..32767 


Identifier der Zielnahe-Bewertungs-Funktion aus VFT 



Fig. 12 



Funktion-ldentifikations-Tabeile: [FIT - Tabelle der Bewertungsfunktions-Fragmente] 
a.) fOr SQL-Funktionen: 

Spalte: Datentyp Wertebereich Bedeutung: 



Function ID (PK) 


signed byte 


-1..127 


IdentifikationsNummer der Teilfunktion 


Function BitCode 


numbed 19) 


0..2 64 *! 


BitCode dieser Teilfunktion 


Function Name 


char(5) 


5 Bytes 


Funktions-Name 


Function Type 


byte 


0..99 


0 = value, 1 = unitar, 2 = binar, 3 = ternar # ... 


Function Ratten 


signed byte 


-127.. 127 


Funktions-Abflachungsgrad [pos = steiler, neg=flacher 


Function Template 


varchar2(99 


<99 Bytes 


SQL-Funktions-Template 


Function Description 


varchar2(99 


<99 Bytes 


bptionale Teilfunktions- Beschreibung 



Fig. 13a 
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F.tD 


Function BitCode 


F.Narrw 


F.T. 


F.F. 


Function Template 


Function Description 


0 


1 


NUM 


0 


0 


< FolgeWert > 


es folgt eine Zahl 


1 


2 


ENGY 


0 


0 


ELT. energy after 


Energie nach Anderung 


2 


4 


GRAD 


0 


0 


ELT. energy _after 
-BJT.energy before 


Energie-Erhohung 


3 


8 


VALUE 


0 


0 


CLT(n). <columnNr> 


Wert aus dem In halt der 
folgeriden Column-Nr 


4 


16 


EREG 


0 


0 


< EnergieRegister ID> 


ID des Energie-Registers 


5 


32 


SGN 




0 


SIGN( %s ) 


Vorzeichen 


6 


64 


ROUND 




0 


ROUNDl %s, 0 ) 


gerundet 


7 


128 


INT 


1 


0 


FLOOR* %s ) 


abgerundet 


8 


266 


ABS 




0 


ABS( %s ) 


Betrag 


9 


512 


NEG 


1 


0 


-( %s> 


Negation 


10 


1.024 


ADD 


2 


1 


((%s) + (%s)) 


Addition 


11 


2.048 


SUB 


2 


-1 


( (%3) - <%S) ) 


Subtraktion 


12 


4.096 


MUL 


2 


4 


( (%s) • <%s) ) 


Multiplikation 


13 


8.192 


DIV 


2 


-4 


( (%s) / (%s) ) 


Division 


14 


16.384 


MOD 


2 


-2 


MOD( %s, %s ) 


Divistonsrest 


15 


32.767 


SQRT 


1 


-8 


SQRT( %s ) 


Quad rat Wurzel 


16 


$1.0000 


CBRT 


1 


-12 


POWER( %s, 1/3 ) 


KubikWurzel 


17 


$2.0000 


MIN 




-10 


LEAST( %s, %s ) 


Minimum 


18 


$4.0000 


MAX 




-10 


GREATEST %s, %s ) 


Maximum 


19 


$8.0000 


LN 


1 


-48 


LN{ %s ) 


Logarithmus naturatis 


20 


$10.0000 


EXP 


1 


48 


EXP( %s ) 


nat. Exponentialfkt. 


21 


$20.0000 


LD 


1 


-32 


LOG( 2, %s ) 


Logarithmus dualis 


22 


$40.0000 


POT 2 


1 


32 


POWER( 2, %s ) 


2-te Potenz von 


23 


$80.0000 


SIN 


1 


-64 


SIN{ %s ) 


Sinus 


24 


$100-0000 


COS 


J 


-64 


COS( %s ) 


Cosinus 


25 


$200.0000 


TAN 


1 


127 


TAN( %s ) 


Tangens 


26 


$400.0000 


ASIN 


1 


127 


ASINI %s ) 


ArcusSinus 


27 


$800.0000 


ACOS 


1 


127 


ACOS( %s ) 


ArcusCosinus 


28 


S 1000.0000 


ATAN 




-127 


ATAN( %s ) 


ArcusTangens 


29 


$2000.0000 


SINH 




40 


SINH( %s ) 


SinusHyperbolikus 


30 


$4000.0000 


COSH 


1 


50 


C0SH( %s } 


CosinusHyberbol. 


31 


$8000.0000 


TANH 




-127 


TANH( %s ) 


TangensHyperbol. 


32 


$1.0000.0000 


LOG 


2 


-64 


L0G( %s, %s ) 


Logarithmus 


33 


$2.0000.0000 


POT 


2 


64 


POWER! %s, %s ) 


Poterizierung 


34 


$4.0000.0000 


OR 


2 


1 


( (%s) | (%s) ) 


bitweises ODER 


35 


$8.0000.0000 


AND 


2 


-1 


{ (%s) & (%s) ) 


bitweises AND 


36 


$10.0000.0000 


EQ 


2 


-127 


DECODE! %s, %s, 1,0) 


gleich 


37 


$20.0000.0000 


I.E 


2 


-127 


DEC0DE( GREATEST %s - %s, 
0), 0, 1,0) 


kleiner-gleich 


38 


$40.0000.0000 


GE 


2 


-127 


DEC00E( LEASTt %s -%s, 0 ), 0, 
1,0) 


grofier-gleich 


39 


$80.0000.0000 


FRAME 


1 


-10 


GREATEST LEAST( %s, +127). 
-128) 


in signed-byte Rahmen: 
max.= 127, min. = -128 


40 


$100.0000.0000 


BITS 


1 


-64 


(1 & %S) +li Ot 70SJ/Z +14- Oi 

%s)/4 +(8 & %s)/8 + .... 


a ri-mKl Rife 1m \//"\rin^ n 

Anzani bus im vuriytsn 
Wert 


41 


$200.0000.0000 


S_REG 


0 


0 


ADT .all ^source _Register$- 
BitCode 


Queltregister-BitCode 


42 


$400.0000.0000 


D REG 


0 


0 


ADT.a// dest Registers BitCode 


Zielregister-BitCode 


43 


$800.0000.0000 


AIM_F 


0 


0 


VAU ADT. aim fulfilled 'flag- 
Function ) 


Ergebnis der Ziel- 
erreichungsfunktion 

















Fig. 13b 
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bj FQr Maschinensprache-Funktionen: 



Function ID (PKJ 


signed byte 


-1..127 


Identif ikationslMummer der Teilf unktion 


Function BitCode 


numbert19) 


0..2 64 -! 


BitCode dieser Teilfunktion 


Operations BitCode 


number 


0..2 ,28 -1 


BitCode der verwendeten OpCodes in dieser Funktion 


Registers BitCode 


number 




BitCode der verwendeten Register in dieser Funktion 


Function Name 


char(5) 


5 Bytes 


Kurzbezeichnung der Teilfunktion 


Function Type 


byte 


0..99 


0 = value, 1=unitax, 2 = binar, 3 = ternar, ... 


Function Flatten 


signed byte 


-128. 127 


Funktions-Abflachungsgrad (1 =f(x) = x) 


Function OpCodes 


number 


1..2 128 -1 


Teilfunktion in Maschinensprache 


Function Description 


varchar2(99 


:£99 Bytes 


options le Teitfunktiona-Beschreibung 



Fig. 14a 


Func.lD 


Func. BitCode 


Oper. BitCode 


Reg.BitCodt 


Func, Name 


F.r. 


Func. OpCodes 


Function Descript 


0 


1 


OA000.4008 


< energy > 


FRAME 


1 


s.u. Fund 


Qberiaufe verhindem 


1 


2 


128800.0009 


< energy > 


SON 


1 


s.u. Func. 2 


Signum (Vorzeichen) 


2 


4 


$0000.0002 


< energy > 


NEG 


1 


<NEG> 


Negation 


3 


8 


$0000.0200 


< energy > 


MUL2 


i 


<SHLI> 


Division durch 2 


4 


16 


$0000.0400 


< energy > 


DIV2 


1 


<SHRI> 


Multiplikation mit 2 


5 


32 


$0000.0100: 
4A00.8018 


<D0> |<en) 


IL0G2 


1 


s.u. Func. 3 


Logarithmus dualis 


6 


64 


S1000.COOO: 
0000.0000 


<FP0>|<en) 


ISQRT 


i 


s.u. Func. 4 


Square-Root 


7 


128 




s. 1.4.2 


ICBRT 


1 


s.o. 1.4.2 


Cube-Root 


8 


256 


$0000.8000 


<en-1)|<en) 


MOV 


2 


<M0V> 


Kopieren in Reg. vor 
Energy-Reg. 


9 


512 


$0000.8000 


<en-1)|<en) 


SWAP 


2 


s.u. Func. 5 


Vertauschen mit 
Reg. vor Engy-Reg. 


10 


1024 


$0001.0000 


(en-1) Ken) 


ADD 


2 


<ADD> 


Addition mit -"- 


11 


2048 


$0002.0000 


(en-1>|<en) 


SUB 


2 


<SUB> 


Subtraktion 


12 


4096 


$0004.0000 


<en-1)|<en> 


MUL 


2 


<MUL> 


Multiplikation 


13 


8192 


$0008.0000 


(en-DKen) 


DIV 


2 


<DIV> 


Division 






















Fig. 14b 





Funktion: 


OpCodes von: (Maschinencodeuberset2ung u.g. Mnemonics, hier am Beispiet Motorola) 


Fund 


CMPi 127,<E> ; JLE <+2> ; MOVI #127,<E> ; CMPI -128,<E) ; JGE (+2) ; M0VI #-128,<E 


Func.2 


TST <E> ; JGE <+3) ; MOVI #-1,<E> ; JMP (+5) ; JGT (+3) ; MOVI #0,(E> ; JMP < + 2) ; 
MOVI#*1,<E> 


Func. 3 


MOVI #31, DO; BTST DO,<E> ; JEQ<43>; DJMP D0,<-2> ; ADDI#1,D0; MOVE D0,<E> 


Func.4 


FILD <E> ; FSQRT ; FIST (E) 


Func. 5 


M0VE<E-1>.-(A7); MOVE (E),(E-1) ; MOVE (A7) + ,<E> 


Fig. 14c 



Bewertungs-FunktioaS'TabeUe: 



Zeichnungen Seite 11/19 
[VFT (valuation f.) - Tabeile der Bewertungsfunktionen] 





signed snort 


± /Of 


IHont-ifiar Hor RovA/orti tnncf i ink tinnAn fFflflrnift DAQ 1 

lUCllllIlCl UCl DoWOI IUI iyOIUII(VllW»l TOM llo^W 


ValuationFunctionJType 


chart! ) 


C | A 


t = tnargra-Deweriung, m — wenvomyiveii iur 
Programmieaieterreichung, (ggf . spater weitere) 


VdiUciuon runcuon iviuuc 


hnnlpan 




0= SQL-Modus; 1 = Maschinencode-Modus 


Valuation Function 


varchar2(99 


<99 Bytes 


Bewertungs-Funktion bzgl. Energie oder Zieierreichung 


execution counter 


integer 


0-2 32 -1 


Anzahl der Funktions-Benutzungen 


used Functions BitCode 


number! 19) 




BitCodes der verwendeten Teitfunktionen 


Function ID Chain 


varchar2(99 


599 Bytes 


Verkettunq der Teilfunktionen (ie Byte = Function ID) 


avg Func execution time 


Integer 


0-232-1 


mittlere Ausf Ohrungszeit der Bew.Fkt in Taktzyklen. 


boundary value counter 


integer 


0-2 32 -1 


Zahlerf. Bewertungsergebnis = -128 1+127 


low value counter 


integer 


0-2 32 -l 


ZShler f. Bewertungsergebnis in ±-16 


ValuationFunctionvalue 


signed byte 


-128..127 


Wertvolligkeit der Bewertungsfunktion = SAC.Se/f- 
Valuation Aim/Energyi Valuation Function, Values ) 



ID 


T y 


M 


Valuation Function 


-1 


'E' 


0 


MAX[ MIN[ SGN( EnergyReg'-EnergyReg 0 ) • SQHT( Energy Reg '-Energy Reg ° ) 
-32- Jl CLJ[\).Register changed BitCode &( I 2 A Energy Register ID)) , +127], -128] 


0 


'A' 


0 


MAX] MIN[ 16-71 CLT(i). Register _changed ^BitCode & M>1 .all _dest Register BitCode ) 
+ 16-71 CLT(i). Register _source_BitCode & ADl.afljsourceRegisterBitCode } 
+ 32- ADT.aim_fulfifled_Flag_Function{ AimJD ) -CLT(i). Processor JAode_changed 
-%-CLT(i). cycles of execution -( CLT(i). active \inactive jChkSum corrupt ) 
-( ClJ(\).Exception_vectj:hanged>0 ) -( CLT "(i). Number _of_Exception>0 I 
-%( CLT(i). ObCode length or jump > 4 oder < 0 ). +1 27], -1 28] 


ex# 


used F. BitCode 


Function ID chain 


ex.T 


bdy# 


k>w# 


F.Val 


0 


$189.0040.983B 


2,5; 2.15; 12; 4,22.3,11,35,40,1,32,12; 1 1 ; 39 


0 


0 


0 


0 


0 


$EE9.0001.3AAA 


3,11,42,35,1,16,12; 3,12.41,35.1.16,12,10; 
43,1,32,10, 3,7,11; 3,16.1,5,13,11; 3,3.11; 3,5,11 
3,5.5,10; 3,8,5,10; 3,9,1,0,37,1 1;3.9. 1,5,38,1 1 ;3S 


0 


0 


0 


0 



Fig, 15b 



Statusieile Kunstfiches BewuBtsein: [SAC (artificial consciousness) - Statuswerte des KB-Programms] 
Spalte: Datentyp Wertebereich Bedeutung: 



Program m StartDate 


timestamp 


Zeit+Dat. 


Datum uns Uhrzeit des Prog ra mm starts. 


actual Processor Mode 


integer 


0-2 32 -1 


Flaqs uber CCR j Control-Repister-Bits 


actual CPT index 


byte 


1.255 


CBT( rr\ax(\)= actual CPT Nr ) = akt.CPT 


CxT counter 


short 


1.. 65535 


Anzahl des Aufbaus der dynamischen CxT-Tabellen 


Aims total 


short 


1.65535 


Anzahl der Programmierziele insgesamt 


Aims soluted 


short 


0..65535 


Anzahl geloster Programmieraufgaben 


actual Aim ID 


short 


0..65535 


ID des aktuellen Proarammierziels 


Aim_Valuation_Mode 


boolean 


on 


Modus der Zielerreichungs-Bewertungsf unktion 
0= SQL-Modus ; 1 - Maschinencode-Modus 


Aim_Valuatk>n_FunctionlD 


signed short 


0..32767 


Aktuelle VFT. Valuation Junction JD bzgl. Ziel- 
annaherunps-Bewertunq 


Aim_Self_Valuation_Func 


varchar2 
(400) 


max.400 
Zeichen 


PL/SQL-Bewertungsfunktion bzgl. der Effizienz der 
Rahmen-Zielerreichungs-Bewertungsfunktionen 


Energy_Valuation_Mode 


boolean 


on 


Modus der Energie ha ndlungs-Bewertungsf unktion 
0 = SQL-Modus ; 1 = Maschinencode-Modus 


Energy Valuation Func ID 


signed short 


-1.. -32768 


Akt. V FT. Valuation Function IDbzQl Energie-Bewert. 


Energy_Setf_Valuation_Func 


varchar2 
(400) 


max.400 
Zeichen 


PL/SQL-Bewertungsfunktion bzgl. der Effizienz der 
Energie-Bewertungsfunktionen 


max Valuation Function 


signed short 


0..32767 


hochste ID aller Bewertungsfunktion en in der VFT. 




signed short 


-1.. -32768 


niedrigste ID aller Bewertungsfunktionen in der VFT. 



Fig. 16 
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Energie-Lern-TabeHe: [EL T - bewertet energiespezifische anfangsbedingungsabhSngige Hand/unpen] 
Spalte: Datentyp Wertebereich Bedautung: 



tnergy_8CTion f ~a/ 


numDer 


n 9128.1 


may 1ft Rutp OnPnHn- Karri hinatian der Eneraie- 
RanioTAr vnrftndernden Handluna 

n lOlul voiai iuvm iuvh i ioiiwmiiy> 


IniConNr (PK) 


signed byte 


-31.. 30 


Anfangsbedingungs-Nr. 


Energy before 


integer 


0..2 32 -1 


Energie-Register vor dieser Handlung 


Energy after 


integer 


0..2 32 -1 


Energie-Register nach dieser Handlung 


min Operations BitCode 


number 


0..2 12 »-1 


BitCode der wahrscheinlich benutzten Operationen. 


max Operations BitCode 


number 


0..2 128 -1 


BitCode atler mogiicherwetse benutzten Operationen. 


Register changed BitCode 


number 


1..2 128 -1 


BitCode der hierbei veranderten Register. 


Register source BitCode 


number 


1..2 12 8-1 


BitCode der hierbei ausgelesenen Register. 


used cycles of execution 


short 


1.. 66635 


Ausfuhrungszeit der energiespezifischen Handlung 


Energy valuation 


signed byte 


-128.. 127 


Ergebnis der akt. VFT.Energy valuation Function 


Valuation Function ID 


signed short 


-1.. -32768 


benutzte Energie-Bewertungsf unktion 



Fig. 17 



Enargia-Basis- Ta belle: [EBT - Auswertung der energiespezifischen Handiungen] 
Spalte: Datentyp Wertebereich Bedeutung: 



Enargy action (PK) 


number 


0..2 128 -1 


max. 16 Byte OpCode-Kombination der Energie- 
Register verandernden Handlung. 


Execution counter 


byte 


0.-255 


Anzahl der ELT-EintrSge bis jetzt 


FatalError_counter 


byte 


n irk 


Mnzan i aer verursacnten scnwcrcii ramci. 
schwere Fahter entsprechen den Spalten 3-7 der 
Lern-Tabelle. auSer wenn Number_of_Exception = 
Devide-Error oder Overflow. 


tow Error counter 


byte 


0..255 


Anzahl der Devide-Error oder Overflow -Exceptions 


avg Energy after 


integer 


0-.2 32 -1 


mittlerer Energie-Wert nach dieser Handlung 


all_Reg_dest_BitCode 


number 


0..2 128 -1 


iJ ELT.Register changed Bitcode V ELT(OpCode) 


cut_Reg_dest_BitCode 


number 


0..2 128 -1 


CELT. Register changed Bitcode V ELT(OpCode) 


allRegsourceBitCode 


number 


0..2 128 -1 


S ELT.Register source Bitcode V ELT<0pCode) 


cutRegsourceBitCode 


number 


0..2 128 -1 


CELT. Register source Bitcode V ELT(OpCode) 


maxOperationBitCode 


number 


0..2 128 -1 


isELT.max Operation BitCode V ELT(OpCode) 


min Operation BitCode 


number 


0..2 128 -1 


CELT.min Operation"* BitCode V ELT(OpCode) 


all_Operation_BitCode 


number 


0..2 128 -1 


■sELT.min Operation BitCode V ELT(OpCode) 


cut_Operation_BitCode 


number 


0..2 12£ M 


CELT. max Operation BitCode V ELT(OpCode) 


max write value 


integer 


0..2 32 1 


Maximun aller geschiebenen Energie-Werte 


min write value 


integer 


0..2 32 -1 


Minimum aller geschiebenen Energie-Werte 


avg write value 


integer 


0..2 32 -1 


Mittelwert aller geschiebenen Energie-Werte 


max write gradient 


integer 


0..2 32 -1 


maximale Differenz des geanderten Enerqie-Werts 


min write gradient 


integer 


0..2 32 -1 


minimale Differenz des geanderten Energie-Werts 


avg write gradient 


integer 


0..2 32 -1 


durchschnittliche Differenz des geanderten Werts 


equal value probability 


signed byte 


-128.. 127 


Wahrscheinlichkeit: Ergebnis immer gleich 


avg Energy gradient 


signed int 


±231 


mittlerer Energie-Gradient dieser Handlung 


equal Gradient probability 


signed byte 


-128.. 127 


Wahrscheinlichkeit: Gradient immer gleich 


avg cycles of execution 


short 


1.. 65535 


Ausfuhrungszeit der energiespezifischen Handlung 


avg Energy_ valuation 


signed byte 


-128.. 127 


Ergebnis der akt. VFT.Energy valuation Function 


Valuation Function ID 


signed short 


-1.. -32768 


benutzte Energie-Bewertungsf unktion 



Fig. 18 
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3.2 Flufidiagramm das KB-Programms: 



3.2, 1 CxTfO-Wertezuweisungen: 
ORTbzw. C8W): 



ORT.Register_ID_dest := log 2 ( Bit(OLT.Register_changed_Mask), dessen Veranderung hier 
betrachtet wird ) 



ORT.Register_ID_source := Register ID( C° ), if ORT.calculation code > 0, sonst-1. 



ORT. value before change := value( Register ID dest), vor OpCode-Ausf uhrung. 



ORT. value after change := value (Register ID dest), nach OpCode-Ausf uhrung 



ORT.gradiant if signed : = MAX| MINI ORT. value after change - ORT. value before change, +1271, -128] 



ORT.gradient rf unsigned := MAX[ MINI ORT. value after change - ORT.value before change, +1271-128] 



ORT.Operation_BitCode : = 1(Rags'^lags 0 )&&V(V-V 6 )&&[ NF&&(V,°<0) 1 1 ZF&MV,°=0) ] 
+ 2'KV, , = -V| 0 )ft&V(V»V 0 )] +4[(V I '=-V|°)&&V-(V«.V°)1 +8[(V,' = 0LB)&&V(V=V°|] 
+ 16 l(V l '=V l o + 0LB)&&V(V , cV o )]-H32.[(V l '=V, o -0LB )&&V-(V' = V°)] + 64.[(V, , =V l o .0LB)&&V(V , «V 0 )] 
♦ 1 28-[(V,' = V, °/OLB)&&V-(V'=V 0 )] + 256-H V,' = V,°%0LB)&&V-(V'-n] + 512.1^' -V^OLBftaVTT-H 
+ 2 10 4<V, , =V, o /2'0LB)&&V^^ 
+ 2 1 3(RagsVRags°)&&V(^^ 

^^.(RagsVRags^&fiiVIV^V^&f MF&&(V,° < 01B)| |ZF&&(V,° =0LB>] + 2 15 -KV,' =C,°)&&V-(V'=V 0 )] 

+ 2 25 (RagsVRags 0 }&&V(V'-V 0 )&&l(ZF-1)&&(2 A C l 0 hV,°>| |(ZF=0)&&l(2 A C l o |V,°) ] 
+2 26 (RagsVRags 0 )&&V(V , =V 0 )&&[ NF&&(V,° <C, 0 )| |ZF&&(V,° =C,°) ] 
+ 2 27 -[(IP t < IP°)| |(IP , >IP°*4)]&&(nags , -Rags 0 )&&V(V , »V 0 ) 

+2 28. [( ,p s , P «)| |0P < >lP° + 4)]&&(nags , = Rags°)&&V(V'=V D )&^NF&!VF|!NF&VH + ...VJcc(CCR) 
+ 2 4 °.{|(IP' < IP°) | j (IP* > IP 0 +4)]&&(V,' =V I °-1)||(V I , = -1 )}&&(Rags' =Rags°)&&V(V'=V°) 
+ 2 41 [( IP=IP°±OLB)$&((SP) = IP° )&&(Rags , =Rags°)&&V-(V'=V°) 

+2 42 [( IP 1 =-4(SP) )&&(Rags'=Flags 0 )&&V(V , =V o )+2 43 '[(V ( W, 0 )&8i(l otherJnteger OperationJitCode)] 
+ 2 44 [(V F VV F °)&&(t other HoaiingPoirrt_Dperation_BitCorJe)]+ 2 45 t(CCR-Hags'=0)&&V(V F * =0)]- 

+2 46 «[{V I ' = c F °)&&v*or=v°)] + ^.[(Vp' =C|°)&&v-(v«v o )] + 2 48 t(v F , = v F ° +c, o )&&V'(v'=v o |] 

+ 2 49 ((V F * = V F «-C I °)&&V^^ 

+ 2 52 (flapVRags 0 )&&V(V'-V°)&&t NF&&(V F ° <C,°) | |ZF&&(V F ° =C, 0 )] 

+ 2 63.[ (V F ' = 1.0)|| (V F ' = 0.0) 1 1 (V F * = n)\ | ( V F ' = e) ]&&V(V= V°) 

♦ 2 54 .[(Vp < = -Vp°)&&(V F ° < 0)&&V"(V^V°)] + 2 55 {(V F ' = C F °)&&V-(V f =V°)] 

+ 2 56 [[v F ' = v F ° +c F °)&&v(\r-v°)] + 257.«v F ' = v F °-c F °)&&v-or-v o )] 

+ 258.[(Vp , = V F 0 Cp 0 )&&V-(V'oV 0 )] + 2 59 .t(V F ' = V F VV F 0 )&&V-(V , =^ 

+ 2«MV F ' =sin(Vp 0 )]&&V-(V , =V 0 )-»- 2 62 .[V F ' =cos(V F °)]&&V-|V=V 0 ) + 2 63 .[(V F ' =atan(V F 0 ))&&V-|V*=V 0 )] 
+ 2 64 -[(V F ' = V F ° ^Vp.-, °)&&V-(V'=V 6 >] + 2 65 *[(Vp' = Vm •log 7 (V F °)&&V-|V'=V°)] 
+ 266.(Rag S VRags 0 )&&V{V , =V°)&&[ NF&&(V F ° <C F °) | |ZF&&(V F ° = C F °)] + 2 57 .[(V,' =C S °)&&V-(V=V°)] 
+ 2 68 [(V $ , = C, 0 )&&V*(V , -V 0 )] + ..., mit V = value_after_change H Flags), V° = value_before_change, 
C° =value(Register_ID_source). Es mufc hierbei uber alle Regis ter_ID_source{ Art) gechecked 
werden. Trotz gleichen Register-ID's im PK kdnnen mehrere Bits gesetzt warden [z.B. wg. 
4=2+2 = 2*2 = SHL(2)=...] ; ' 



Fig. 19 

OLTbzw. CLTW: 



OLT.ProcessorJv1ode_Changed : = 71 EFIagj*/Sr\, & ! S , 2 A CCR_Flags } > 0 
ORT.value after_change( Register ID eines Spezial-Registers ) 



OLT.aim_valuation := VFT.Aim_Valuation_Function( SAC.Aim_Valuation_FunctionlD, ORT.xxxxx, 
Registers_changed_BitCode, Registers_source_BitCode, min_Operations_BitCode. 
max OperationsBitCode, used cycles _of_ execution, ... ) 



CLT(n). gradient aim_valuation := CLT(n).aim_valuation - CLT(n-1).aim valuation 

alle anderen Tabellenfeld-Zuweisungen sind anhand der OLT-Beschreibung in Fig.6 hinreichend erklart. 



Fig.20 



' Zeichnungen Seite 14/19 

OBTbzw. CBWh 

OBT. Execution counter :- Execution counter + 1 

OBT.FatalError_counter := Fatal Error_counter + (0 < OLT.Number_of Exception * Devide_Error / 

Overflow ) 1 1 OLT.active_ChkSum_corrupt 1 1 OLT.inactive_ChkSum_corrupt 1 1 

OLT.Exception vect changed | [ OLT. Processor Mode changed ) 

OBTJumpJongOpjprobability := MAX[ MIN[ Jump_probability + (OLT. OpCodeJength_or Jump < 0 ) 

+ (OLT.OpCodeJength or jump > 4), + 1 27], -1 28} . 

OBT.avg OpCodeJumpJength : = (execution_counter*avg_OpCodejump_length 

+ akt.OpCode Jump length) / (execution counter* 1) 

OBT.0pCodeJen_unconfirmed := OpCodeJen_unconfirmed 1 1 ( avg_OpCodeJength * 

akt.QpCode length ) 

OBT.avg_cycles_of_execution : = ( execution_counter * avg_cycles_of_execution + 

akt. cycles of execution ) / (execution counter + 1) _ 

0BT.exec_cyc1es_unconfirmed :- exec_cycles_unconfirmed || (avg_cycles_of_execution * 

akt. cycles of execution ) 

OBT.Registerj/vrite_probability : - MAX[ U\U\ Register_wrtte_probability + 2*[ ( min.Reg.ID <> 

ORT.ColumnJD OLT £ max.Reg.ID )&& ORT.value_before_change * ORT.value_after_change ] - 

1, +127], -128f _____ 

OBT.Register_copy_probability := MAX[ MIN{ MIN( Regis*ter_copy_probability + 2*[ ( min.Reg.ID _ 

ORT.Column J D_OLT < max. Reg. ID )&& ORT.value_before_change * ORT.value_after_change 

&&( min.RegTlP"- ORT.Column ID source <> max.Reg.ID ) ] -1, + 127], -128] 

OBT.Memory_write_probabiiity := MAX] MIN[ Memory_write_probabiiity +2*[ ( min.Adr.RegJD £ 

ORT. Column J D_OLT _ max.Adr.Reg.ID )&& ORT.value_before_change * 

QRT.value after change ] -1 , + 1 27], -1 283 _ 

OBT.Memorycopyprobability := MAX| MIN[ Memory_copy_probability + 2*[ ( min.Adr.Reg.ID <, 
ORT.Column_ID_OLT < max.Adr.Reg.ID )&& ORT. value J>efore_change * 

ORT.value_after_change &&( min.Adr.Reg.ID 5 ORT. Column I D_source <> max.Adr.Reg.ID ) ] -1, 

+ 127], -128] 

OBT.Reg_to_Mem_probability := MAX[ M1N[ Reg_to_Mem_probability + 2*[ ( min.Adr.RegJD < 

ORT.CoiumnJD_OLT _ max.Adr.Reg.ID )&& ORT.value_before_change # ORT.valuejafter- 

change &&( min.Reg.ID < ORT.Column ID source £ max.Reg.ID ) ] -1, + 127], -128] 

OBT.Mem_to_Reg_probability : = MAX[ MIN[ Mem_to_Reg_probability +2*1 ( min.Reg.ID < 

ORT.ColumnJD_OLT < max.Reg.ID )&& ORT.valueJ>efore_change * ORT.value_after_change 

&&( min.Adr.RegJD < ORT.Column ID source < max.Adr.RegJD ) ] -1, +127], -1 28] ' 

OBT. Mult i_Reg_ write _prbb := wie bei Register jA/rite_probability, jedoch mit min.2 zutreffenden 

ORT.Column ID OLT -Eintragen. ■ 

OBT.Multi_Mem_write_prob : = wie bei Memory_write_probability, jedoch mit min.2 zutreffenden 

ORT.Column ID OLT -Eintragen. 

0 BT . Mult i_R eg_to_Mem_prob := wie bei Reg_to_Mem_probability, jedoch mit min.2 zutreffenden 

ORT.Column ID OLT + Cotumn ID source -Eintragen. 

OBT.Multi_Mem_to_Reg_prob := wie bei Mem_to_Reg probability, jedoch mit min.2 zutreffenden 

ORT.Column ID OLT + Cotumn ID source -Eintragen. 

OBT.xxx Reg source | dest BitCode: siehe Tabellenbeschreibung 

OBT, xxx calculation BitCode: siehe Tabellenbeschreibung : 

OBT. max write value := MAX( max_ write value, QRT.value after change ) 

OBT.min write value : - MIN( min write value, ORT. value after change ) m 

OBT.avgwritevalue : = ( execution counter * avg_write_value + ORT.value_after_change ) / 

(execution counter* 1) „ 

OBT.max_write_gradient : = MAX( max_write_gradient, ORT.value_after_change - 

ORT.value_before change ) m _ 

OBT.minwritegradient := MIN( min_write_gradient, ORT.value_after_change - 

QRT.value before change ) ' 

OBT.avg write_gradient : = ( execution_counter * avg_write_gradient + ORT.value_after_change - 

QRT.value before change ) / (execution counter + 1) . _ 

OBT.evaluated_sourceJNum]Register := Wahrscheinlichkeitsfunktion( xxx_Reg_source_BitCode, 

confirmation counter) ___ 
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OBT.evaluated dest_Register[2] := Wahrscheinlichkeitsfunktion( xxx Reg dest BitCode, confirm, ctr.) 
OBT.evaluated OperationJD : - Wahrscheinlichkeitsfunktion< xxx Operation BitCode, confirm.ctr. ) 
OBT.Confirmation_counter := Confirmationcounter + ewsft aquivalenter OLT+ORTs-Eintrag mit 

niedrigerer IniConNr ) . 

OBT.max_aim valuation := MAX( max aim valuation, OLT.aim valuation ) 

OBT.avg_aim_valuation : = { executioncounter * avgaimvaluation + OLT.aim valuation ) / 

(execution counter* 1) _ 

CBT(n).max_grad_aim_valuation := MAX( CBT(n)max_aim valuation, CLT(n).aim_valuation ) 

- CBTIn-D.max aim^valuation. 

CBT(n}.avg_grad_aim_valuation : = { execution_counter * C BT(n). a vg_ai revaluation 

+ CLT(n).aim valuation ) / (execution counter* 1) - CBT(n-1).avg grad aim valuation 

Ffg.27 

3.2.2 ELT und EBT -Wertezuweisungen: 

ELT.max Operations, BitCode := OLT.max Operations OpCode 

ELT.min_ Operations_BitCode : = OLT.min Operations OpCode 

ELT. Register changed_BitCode := OLT. Registers changed BitCode 

ELT.Register source BitCode := OLT.Registers source BitCode 

ELT.Energy Valuation := VFT.Energy_valuation_Function( SAC.Energy_Vatuation_FunctionlD, 

Energy_after, Energy before. Registers_changed_BitCode, Registers_source_BitCode, 

min Operations BitCode, max Operations BitCode, used cycles of execution, ... ) 

ELT.Valuation_Function_ID := zur Berechnung von Energy ^Valuation benutzte 

VFT. Valuation Function ID 
EBT.avgEnergyafter := ( execution counter • avg_Energy_after + ELT.Energyafter ) / 

(execution counter* 1 ) - 

EBT.equal value probability := equal value probability + 2-( avg Energy after = ELT.Energy after ) -1 
EBT.avg_Energy_gradient := ( execution_counter - avg_Energy_gradient + ELT.Energy_after - 

ELT.Energy before ) / (execution counter* 1) 

EBT.equalgradientjarobability : = equalgradientprobability + 2-( avg_Energy_gradient = 

ELT.Energy after-ELT.Energy_before ) -1 , 

EBT.xxx Operations I Registers_8itCode siehe Tabellenbeschreibung 

EBT.avg cycles of execution := ( execution_counter * avg_cycles_of_execution + ELT.usedcycles- 

of execution ) / (execution counter* 1) 

EBT.avg_Energy_ Valuation :« ( execution_counter • avg_Energy_Valuation + ELT.Energy^valuation ) 

/ (execution_counter+ 1 ) 

Fig.22 

3.2.3 Def/nitionen zum Lesen des FfuBdiagramms: 

Anweisungen | kennzeichnet eine Anweisung oder eine Anweisungsfolge. 
( Bedingung erfuHt ? ) JA: verzweigt horizontal, NEIN: unten weiter. 

( CodeFortfuhrung ) kennzeichnet eine Sprung-Marke zu bzw. von einem anderen Teil des FluSdia- 
gramms. 

Anweisungs-Btock [ I kennzeichnet einen Block bereits vorher definierter Anweisungen. 



Im FluRdiagramm sind aufgrund der Aufwendigkeit nicht alle Details akribisch beschrieben, jedoch 
ist die Grundlage der Funktionsweise klar und verstandlich dargelegt. Seibstverstandliche Dinge, 
wie Cursor-Close, oder das mitfiillen nicht explizit erwahnter, aber vorhandener und keinen 
besonderen Algorithmus benotigender Tabellenfelder, gilt als selbstverstandlich angenommen, da 
die Bedeutung der Tabellenfelder bereits unter 3.1.2 erklart ist und deren Zuweisungen unter 
3.2.1 bzw. 3.2.2. 

Im FluGdiagramm bedeutet "Eintrag in der ORT generieren und OBT aktuatisteren" einen Verweis 

auf die Wertzuweisungsalgorithmen in Fig. 19-21. 

Fig.23 
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3.2.5 KB-Flu&diagramm: 

a.) Initiate Vorbereitungen: 



lalle Registerinhahe abspeichern. 



| alle Original-Exception-Vektoren sichem. "1 

4 



IProzessor in Ausgangszustand bringen: alle Breakoints loschen, die Flags in den Control- I 
Register und iim oberen Word des Status/Flags-Registers initiieren. I 

, i 

| KB-Datenbank (s.o.) anlegen und inltlale Tabellenwerte laden (bzw: errechnen). I 

|alle Exception-Vektoren auf eigene Abfangroutinen umlanken. I 



fur Exceptions, die zusatzliche Daten auf dem Stack abspeichern, eine besondere Exception-! 
Routine, die die zusatzlichen Paten mitberucksichtigen. 1 



Eine Exc.-Vektorroutine zum hochschalten in den Supervisormodus misbrauchen und diese 
Exception ausldsen (Prozessor schaltet dart in den Supervisor-Modus und arbeitet ab dieser 
Vektoradresse weiter, wo auch der weitere Programmverlauf steht). n 



Auf dem Stack die EFIags* bzw. das Statusregisters„ so poppen, daS bei dessen Ladung, 
beim Rucksprung aus dem Supervisor-Modus, das Trace^/Trap^-Flag gesetzt ist, urn danach im 
Single-Step-Modus zu sein. 



r 



Auf dem Stack den EIP n /PC w so poppen, daft bei dessen Ladung, beim Rucksprung aus deml 
Supervisor-Modus, an einer vorgesehenen Teststelle fQr OpCodes fortgefuhrt wird. | 



Initiate Testwerte, die dann zum OpCode-Test in die Register geladen werden, so vorbereiten, 
daS dann alle Registerinhalte unterschiedliche Werte aufweisen und auch an den Orten der 
Adressregister-Verwetse unterschiedlieche Zahlen stehen. 



| DWord-OpCode Generator-Zahler auf -1 = $FFFF.FFFF initiieren. 

4 

| IniConNr-Zahler auf -32 initiieren. 

Fig.24a 



b J Basis-Lemen: 
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lOpCode-Generator-Zahler urn 1 erhohen und lniConfMr = -32 initiiernT"] 



( Hat OpCode zum_2.maf $OQQ&QPOO erreicht ? y+(_Handlungs-Lemen (Fig.24c) ) 

MniConNrum 1 erhdhenH * I DB-Commit | 

< (lnjConNr>30 ?> 

'~X~~ 



Alle Register-Werte und Adressregister-Verweisinhalte auf ICT.Register value( IniConNr ) set- 
zen; ab Teststelle 8 x NOP schreiben (dahinter steht die Fehlerroutine fur Trace^/Trap n -Flag 
geldscht) und generierten OpCode-Wert dariiber an die Teststelle schreiben. 



Rucksprung aus dem Supervisor-Modus ausfuhren: Test-EFIags^/SR^ werden geladen und 
dabei das Single- Steppe n eingeschaltet. Der EIP n /PC w wird mit der Test-OpCode-Stelle 
geladen und der dortige Test-OpCode ausgef uht. 



Analyse: 



Nach der OpCode-AusfOhrung wird die Wirkung seiner Ausfuhrung 
anaiysiert und das Ergebnis in einem Analyse-Code gespeichert: 



| In der Lern-Tabelte Eintrag mit Key= {OpCode, IniConNr), confirm, counters generiere'nH 



OLT.Number of Exception, Flags _be- 
fore execution, etc. eintragen; OBT* 



< Wurde eine Non-Trace : ExceptignausgeidstJ) -^ 

I i 

< Wurde uberhaupt keine Exception ausgefost ? y> | OLT.Processor Mode changed, OBT* 1 — ► 



es wurde Trace/Trap ausgeldst - Analyse der OpCode- A uswirkung: 



I KB-Prg.-CheckSum und die Checksum der inaktiven Kopie des KB-Prgramms ermitteln 
< Checksum des aktiven KB-Prg. 's veriindert ? > 



OLT.active ChkSum ^corrupt setzen, an 
aquivalente Stelle des inaktiven Codes 
springen und ehemals aktiven Code repa- 
rieren; OBT* 



< Checksum des inaktiven KB-Prg' s yerandert ? >-> 



inactive jChkSum corrupt-f \ag setzen, 
und inaktiven Code reparieren; OBT* 



( Wurde ein Except/gn-Vektor uperschieben ? >-> 



alle Exception-Vektoren wieder neu setzen, 
in OLT. Exception yector changed dessen N 
eintragen, Eintrag in der ORT generieren; OBT 



Vergleich des &? % IPC U auf Stack (durch Trace gepushed) mit der Test-OpCode-Adresse 
und setzten von OpCodelength or jump entsprechend der Befehls- oder Sprung-Lange. 



( Wurde der iP nicht um 1..4 B ytes erh&ht ? \OLT. OpCode length or jump, u.s.w., OBT* 
+ 



Wenn OpCode kiirzer als DWord war, erhohe Generator auf $ <Byte>FF.FFFF bei Byte- 
OpC, bei Word-OpC auf $<Word>.FFFF und bei 3-Byte-OpC auf $ < Word-Byte > FF. 



I Vergleich des d.Traca genushed EFIags„/SR/, auf dem Stack mit dem vorherigen Test-Wert ~1 



(Wurde ein Registerwert icLF/ags ver§ndert7)~* 



Loop uoer aiie Kegisier: 



Eintrage in der ORT, OLT generieren und OB 
aktualisieren. Wenn "Energie" -Register verSn 
dent: ELT-Eintrag und EBT akttialisieren. 



( Wurde das Ziel eines Adress-Reg. yerandert?y + 
Loop ODer alle Adr.Reg.: | 

i 



ORT- und OLT-Eintrage generieren und OBT 
aktualisieren. 



Fig, 24b 



cj Doppel-OpCode-Handetn: 
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( Begfnn Doppel-OpCode-Handem [nach Ende Basfs-Lernen - Fig. 24b] ) 



OBT-Auswertung: mittels Wahrscheinlichkeitsfunktionen werden evaluated _sourceJNum]Reg[ister J 
aus den OBT.xxx_Reg_source_BitCode , evaluated jdest_Register[2] aus den xxx_Reg_dest BitCode 
und evaluated Operadtion ID aus den xxx Operation BitCode ermittelt (je mit confirmation counter) 



T 



Letztes Datenregister als "Energie'-Register definieren und auf einen mittleren Wert setzen. \ 

i 



[ 



Cursorl uber die OBT offnen. 



Fetch aus Cursor! die nflchste Zeile aus der OBT. 



1 



( Tripfe-OpCode-Planen (Fig. 24c) )i-( Fetch1_empty- vorderer OpCode abgearbeitet ? ) 

/JumpJongOp probability > 0 Oder T[ADT. unused ^Register J3itCode( Aim JD) \ 
\ &(OBT^cutjource Reg_BitCgde}OBT.cut dest_Reg_BitCode) I > 0 ? / 

< Execution _cgunter / OBTOpCodeFatalError counter fOpCodeV < 5 ? ) - 

4^ 1^ 



2. Cursor Qber die OBT offenen. 



Fetch aus Cursor2 aus der OBT. 
1 



< Fetch2 empty - hjnterw OpCode abgearbeitet ? > 



/JumpJongOp probability > O oder Y [ADT. unused Register BitCodeiAim ID) \ 

\ &(QBT.cut_source_Reg BitCode [OBT cut jdest RegjBitCode) 1 (OpC.2) > 0 ? / 

« ( Execution counter / OBT. OpCode FatalError counter (OpCode2) < 5 ? > 

I IniConNr « -32 initiieren. 1 



IniConNri^ 



-( IniConNr > +30 ?) 



Initiierung und AusfQhrung mit den Anfangsbedingungen der IniConNr wie 
beim Basis-Lernen, nur jetzt fur den Doppel-OpCode. 

ir — — — - ^ 



Gleiche Verfahrensweise, wie im Analyse-Block des Basis-Lernens (Fig. 24b), 
nur ElntrSge jetzt in CRT(2) f CLT(2) und CBT(2). 



"Energie w -Register urn 1 erniedrigen. 



] 



(list *Ene rgji^Register hohen Bereich? > 



EBT. Energy specific action mit hoher anergy action valuation und hohem 
confirmation counter auswahfen und ausfuhren. 



T 



Analyseblock wie open. 

T 



Fig.24c 



d.) Triple-OpCode-Planen: 
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( Beginn Triple-OpCode-Planen [nach Ende Poppel-OpCode-Handeln - s.o.l ) 

j 



CBT{2)-Auswertung: mit Wahrscheinlichkeitsfunktionen werden evaluated source JNum]Reg[ister] 
aus den CBT(2).xxx_Reg_source BitCode, evaluated _dest_Register[2] aus den xxx_Reg_dest_BitCode 
und evaluated Operadtion ID aus den xxx Operation_BitCode ermittelt (je mit confirmation counter) 



3 



L 



Cursor 1 uber die CBT(2) affnen. 
1 



L 



Fetch aus Cursor 1 die nflchste Zeile aus der CBT(2). 

1 



( Quad-OpCodo-Ptanen ><-( Fetch 1 empty [• vqrderer OpCode abgearbeitet ? ) 

/ Jump JongOp probability > 0 oder -fjADTunused Register _BitCode( Aim ID) \ 
\ &(OCTJ2fcut source _Reg_BitCqde[OBT(2).cut dest_Reg_BitCode) J > 0 ? / 

( Execution counter / CBT/21 OpCode Fata /Error^ounter (OpCode 1) < 5?) 



1 


Cursor2 uber die OBT 6ffenen. 


I 




U 


Fetch aus Cursor2 aus der OBT. 

i " 


1 



< Fatch2 ernj?t£ - te ? ) 



/ Jump JongOp j>robabiiity > 0 oder Y[ADT. unused _Register_BitCode( Aim _ID) \ 
\ &(OBT.cutj>ourceJ%eg_BitC > 0 ? / 

- ( Execution counter / OBT. OpCode FatalError counter < 5 ?) 

$ 



lniConNr = -32 initiieren. 



lniConNr+ + 



-< IniC onNr > +30 ? > 
I 



Initiierung und Ausfuhrung mit den Anfangsbedingungen der IniConNr wie 
beim Poppel-OpCode-Handeln, nurjetzt fur den Triple-OpCode. 



Gleiche Verfahrensweise, wie im Analyse-Block des Doppel-OpCode-Handelns 
(Fiq.24c), nur Eintrflge jetzt in CRT(3h CLT(3) und CBT(3). 



I Energieregister decremantieren und ggf. gleiche Auffullversuche wie beim 
1 Poppel-OpCode-Handeln mit aquivalenter Handlungsbewertungsanalyse. 



Fig.24d 



Verfahrensweise fur hohere Kombinationen analog, mit CxT(n). 
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